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ABSTRACT 


The  U.S.  Navy  anticipates  moving  to  a  shipboard  high-energy  laser  program  of  record  in 
the  fiscal  year  2018  and  achieving  an  initial  operational  capability  by  2020.  The  design  of 
a  distance  support  capability  within  the  high-energy  laser  system  was  expected  to  assist 
the  Navy  in  reaching  this  goal.  This  capstone  project  explored  the  current  Navy 
architecture  for  distance  support  and  applied  system  engineering  methodologies  to 
develop  a  conceptual  distance  support  framework  with  application  to  the  high-energy 
laser  system.  A  model  and  simulation  of  distance  support  functions  were  developed  and 
used  to  analyze  the  feasibility  in  terms  of  performance,  cost,  and  risk.  Results  of  this 
capstone  study  showed  that  the  implementation  of  distance  support  for  the  high-energy 
laser  system  is  feasible  and  would  reduce  the  total  ownership  cost  over  the  life  of  the 
program.  Furthermore,  the  capstone  shows  that  moving  toward  the  team’s  recommended 
distance  support  framework  will  address  current  gaps  in  the  Navy  distance  support 
architecture  and  will  provide  a  methodology  tailored  to  modem  enterprise  naval  systems. 
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EXECUTIVE  SUMMARY 


In  an  attempt  to  reduce  mean  down  times  (MDT)  and  total  ownership  costs  (TOC),  the 
United  States  Navy  (USN)  is  currently  researching  the  concept  of  distance  support  (DS). 
Distance  Support  is  the  process  of  providing  a  maintenance/support  product  or  service 
from  an  offsite  location. 

The  team  developed  and  analyzed  the  requirements  for  implementing  a  DS 
system  for  the  high  energy  laser  (HEL).  This  included  what  was  necessary  from  the 
perspective  of  the  DS  system  itself,  as  well  as  what  is  required  of  the  HEL  system  to 
provide  a  complete  interface  to  a  DS  system.  A  generic  DS  framework  was  developed  to 
fit  the  USN’s  unique  requirements  and  policies.  While  the  DS  framework  could  be 
applied  to  any  system,  the  HEL  was  chosen  as  the  platform  of  interest  (POI). 

The  team  performed  functional  analysis  and  allocation.  During  this  step,  the  DS 
pillars  (primary  supporting  elements)  and  architecture  were  decomposed  into  the  next 
lower  level  functions.  Additionally,  the  team  started  to  develop  and  refine  the  functional 
interfaces  both  internal  to  the  DS  system  as  well  as  external  to  the  HEL  system.  It  was 
important  to  determine  and  define  the  DS  system  level  boundaries  as  this  would  facilitate 
the  development  of  the  physical  requirements  for  the  DS  system  in  the  next  stage.  The 
system  architecture  diagrams  were  developed  to  describe  the  system.  The  team  chose  to 
use  the  IDEEO  as  the  basis  for  the  conceptual  model  of  the  DS  system  that  was  tested. 
IDEEO  was  chosen  for  DSHEL  because  it  is  well  understood,  adapted  well  for 
information  systems,  and  aligns  to  the  DS  framework  and  platform  service  architecture 
developed. 

Through  the  employment  of  modeling  and  simulation  (M&S)  tools,  the  effects  of 
three  types  of  support  alternatives  were  analyzed:  The  Status  Quo  Distance  Support 
Model  based  on  level  of  repair  analysis  (LORA)  currently  implemented  on  most  USN 
platforms;  the  Integrated  Distance  Support  Model  representing  the  model  that  is  proposed 
in  the  CONORS  of  this  effort;  and  the  No  Distance  Support  Model  consisting  only  of 
sailor  actions  and  contractor  in-port  support.  The  baseline  status  quo  DS  model  (non- 


integrated  DS)  indicated  a  MDT  of  149.0  hours,  a  standard  deviation  of  91.5  hours,  with 
a  resulting  operational  availability  (Ao)  of  0.770.  Integrated  DS  showed  significant 
improvement  with  a  MDT  of  83.8  hours,  a  standard  deviation  of  44.9  hours,  with  a 
resulting  Aq  of  0.856,  an  increase  of  8.5%.  Conversely,  elimination  of  DS  was 
detrimental  to  reliability  with  a  MDT  of  335.1  hours,  a  standard  deviation  of  210.5  hours, 
and  Ao  of  0.559,  decreasing  the  Aq  by  21.1%. 

Cost  analysis,  based  on  a  20-year  life  cycle  of  HEL  installed  on  30  shipboard 
platforms,  resulted  in  an  estimate  of  $7M  for  the  addition  of  a  DSHEL  component.  Given 
30  HEE  platforms,  the  integrated  results  from  M&S  have  shown  that  DSHEE  would 
begin  to  show  a  return  on  investment  once  29  technical  assistance  requests  have  occurred. 

The  conceptual  DS  framework  was  developed  using  a  holistic  systems 
engineering  approach  to  provide  the  HEE  with  enterprise  level  support  at  a  distance.  This 
expanded  level  of  support  reduces  MDT  and  lowers  TOC  when  compared  to  systems 
without  DS.  Therefore,  the  capstone  team  recommends  that  the  Navy  adopt  an  integrated 
DS  framework  approach  for  providing  maintenance  support  to  the  future  HEE  system. 
This  would  include  using  the  team’s  conceptual  DS  framework  and  incorporating  real 
world  data  into  the  capstone’s  M&S  models  and  cost  analysis  to  obtain  a  more  accurate 
understanding  of  the  framework  and  benefits  of  implementing  DS. 
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I.  INTRODUCTION  AND  PROJECT  OVERVIEW 


This  capstone  report  has  been  developed  by  a  team  of  students  at  the  Naval 
Postgraduate  School  (NPS)  in  the  distance  learning  eohort  331-1330  pursuing  either  a 
Master’s  of  Science  in  Systems  Engineering  (MSSE)  or  Master’s  of  Seience  in 
Engineering  Systems  (MSES).  The  team,  all  employees  of  Naval  Surfaee  Warfare  Center, 
Port  Hueneme  Division  (NSWC  PHD),  exeeuted  sound  system  engineering  (SE) 
teehniques  with  extreme  prejudice  and  rigor.  Over  the  course  of  nine  months,  the  team 
performed  research,  analyzed  previous  contributions  to  the  body  of  knowledge  (BoK), 
developed  a  generic  distance  support  (DS)  framework,  performed  functional  analysis  and 
architecture  design,  and  exeeuted  modeling  and  simulation  (M&S)  of  DS  processes 
which  ultimately  fed  a  eost  and  risk  analysis. 

A,  BACKGROUND 

This  seetion  provides  an  initial  baseline  of  knowledge  for  the  subject  matter 
presented  and  relates  its  importance  to  in-service  engineering  in  the  sustainment  phase  of 
the  HEE  life  cyele. 

1.  Distance  Support 

Currently,  DS  is  performed  by  the  United  States  Navy  (USN)  using  the  following 
conduits  (Naval  Surface  Warfare  Center,  Port  Hueneme  Division  2013): 

•  Non-Secure  Internet  Protoeol  Router  Network  (NIPRNET)  chat 

•  Secure  Internet  Protocol  Router  Network  (SIPRNET)  ehat 

•  Email 

•  Phone 

•  Regional  maintenance  center  (RMC)  site  visit 

•  Engineer  on-site  technieal  assistance  (Teeh  Assist) 

•  DS  websites  (Sailor  2  Engineer,  Sailor  2.0) 

When  a  system  indicates  a  fault,  sailors  take  action  to  correct  the  fault  based  on 
their  training,  and  consulting  automated  tools  for  fault  diagnosties.  In  a  mature  system. 


I 


the  automated  systems  may  provide  valid  solutions.  The  next  step  in  diagnosties  and 
troubleshooting  is  to  consult  technical  manuals  and  drawings.  As  systems  have  become 
more  complex  throughout  the  USN,  the  ability  to  effectively  read,  interpret,  and  take 
action  based  on  schematics  has  failed  to  keep  up  with  demand.  As  onboard 
troubleshooting  efforts  are  exhausted,  the  ship  must  contact  outside  shore  support.  RMCs 
provide  the  second  tier  of  service  and  the  in-service  engineering  agent  (ISEA)  the  third. 
These  latter  two  entities  provide  only  as  much  remote  support  and  guidance  as  can  be 
gleaned  from  descriptions  of  problems  from  the  ship  or  limited  output  from  the  system. 
When  troubleshooting  time  or  problem  information  provided  ashore  has  been  depleted, 
an  engineer  or  technician  must  go  aboard  the  ship  to  resolve  the  problem.  The  effort  and 
expense  of  onboard  support  may  be,  in  some  cases,  cost  prohibitive. 

2,  High  Energy  Laser  Weapons  System 

An  example  of  a  fiber  solid  state  laser  (SSL)  prototype  demonstrator  developed 
by  the  USN  is  the  Laser  Weapon  System  (LaWS).  The  USN  plans  to  install  a  LaWS 
system  on  the  USS  Ponce,  a  ship  operating  in  the  Persian  Gulf  as  an  interim  afloat 
forward  staging  base,  to  conduct  continued  evaluation  of  shipboard  lasers  in  an 
operational  setting.  The  USN  reportedly  anticipates  moving  to  a  shipboard  laser  program 
of  record  in  “the  PY2018  time  frame”  and  achieving  an  initial  operational  capability 
(IOC)  with  a  shipboard  laser  in  PY2020  or  PY2021  (United  States  Congressional 
Research  Service  2014). 

Lasers  are  being  used  in  the  commercial  sector  for  a  wide  range  of  projects  from 
eye  corrective  surgery  to  tattoo  removal.  As  with  any  military  product,  the  aspects  of  DS 
and  maintenance  are  much  more  difficult  and  require  more  scrutiny  and  planning.  The 
components  of  a  basic  laser  must  be  considered  for  the  purposes  of  DS  planning. 

Lor  the  purposes  of  DS,  it  is  necessary  to  consider  the  basic  lowest  replaceable 
unit  (LRU)  and  parts  of  a  laser  that  could  potentially  require  attention  or  maintenance. 
All  portions  of  a  laser  must  be  carefully  balanced  and  maintained  to  allow  for  optimum 
efficiency  and  results.  Under  this  assumption,  it  is  important  to  distinguish  the  basic 
LRUs  or  simplest  components  of  a  laser. 
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Since  the  HEL  is  still  relatively  new,  the  knowledge  base  and  policies  in  place 
need  time  to  mature.  Lack  of  past  experience  and  knowledge  increases  risk  in  designing  a 
DS  system,  as  there  is  less  historieal  data  to  leverage.  The  LRUs  of  the  laser  need  to  be 
monitored  in  order  to  prepare  for  and  mitigate  problems  that  may  arise  from  operational 
use  and  environmental  faetors. 

B,  PROBLEM  STATEMENT 

The  USN  has  no  eurrent  plan,  component,  service,  or  system  that  addresses  all 
aspects  of  DS.  This  capstone  report  will  explore  a  methodology  and  design  of  a  DS 
framework  for  a  HEL  system.  Additionally,  a  DS  framework  will  be  established  for  the 
HEL  to  address  feasibility  in  terms  of  eost  and  risk  to  the  USN. 

This  effort  affects  multiple  USN  systems.  When  a  system  is  produced  and 
deployed,  it  is  expected  that  a  eertain  number  of  parts  will  break  or  require  maintenance 
due  to  antieipated  use  and  wear  and  tear,  and  unexpected  casualties.  This  in  turn  will  lead 
to  the  need  to  replace  or  repair  components  of  the  system.  The  DSHEL  capstone  team  has 
developed  a  DS  system  that  is  applicable  to  the  HEL,  while  still  maintaining  a  generic 
architecture  that  is  relevant  to  many  systems  including  possible  future  iterations  of 
different  HEL  weapon  types. 

C.  PROJECT  OBJECTIVES  AND  RESEARCH  QUESTIONS 

This  section  describes  the  project  goals  and  research  questions. 

1.  Project  Goals 

The  goal  of  this  eapstone  report  was  to  develop  a  DS  framework  and  architeeture 
for  future  shipboard  HEL  Systems.  The  team  studied  a  “designed  in”  implementation  of 
DS  rather  than  a  “bolted  on  after  the  faet”  implementation.  Using  the  USN’s  Six  Pillars 
of  DS  as  a  starting  point,  the  team’s  objectives  were  to  explore,  analyze,  and  propose 
methodologies,  arehiteetures,  and  teehnologies  to  efficiently  effeetuate  the  first  four 
pillars  of  DS  as  applicable  to  surface  USN  HEL  Systems.  The  Six  Pillars  are  discussed  in 
subsequent  chapters. 
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2.  Research  Questions 

The  followiug  reseaich  questions  were  answered  by  this  capstone  report: 

•  How  will  DS  affect  the  overall  cost  and  risk  in  HEL  shipboard 
implementation? 

•  What  type  of  infrastmcture  is  requued  to  adequately  perform  DS  for  HEL? 

•  Ar  e  there  any  existing  DS  fr  ameworks  that  can  be  applied  to  DSHEL? 

•  Of  the  HEL  components,  which  mformation  is  the  most  important  to  collect? 

D.  PROJECT  ASSUMPTIONS  AND  CONSTRAINTS 

This  capstone  report  was  execirted  rmder  the  following  assirmptions  and 
constraints  as  detailed  in  Table  1 . 


Table  1.  Assirmptions  arrd  Constraints 

Type 

Assumption  or  Constraint  Description 

Constraint 

This  strrdy  is  limited  to  the  Solid  State  Fiber  Laser  as  the  HEL  system 
bemg  analyzed.  This  laser  has  already  been  used  and  installed  on  a  USN 
ship. 

Constraint 

This  sbrdy  is  limited  to  the  HEL  system  integrated  onto  afloat  platforms. 
Afloat  platforms  were  chosen  dire  to  stakeholder  needs  and  requirements 
as  detailed  later. 

Constramt 

Of  the  Six  Pillars  of  DS,  this  capstone  will  cover  the  first  foin  pillars; 
Remote  Technical  Assistance,  Remote  Repah  and  Validation,  Remote 
Diagnostics,  and  Remote  Monitoring.  The  last  two  pillars  of  DS  are 
outside  the  scope  of  this  capstone  repoif  as  the  technology  available  is 
not  yet  matm  e  enough  to  support  ePrognostics  or  Self  Repair  and 

Healing. 

Constraint 

All  data  and  information  disclosed  withui  this  capstone  report  has  been 
generalized  to  conform  with  Distribution  A  requuements  for  release  to 
the  public. 

Assirmption 

Labor  rates  of  support  persoimel  ar  e  frilly  biu  dened  at  $  60/hr'.  This  value 
was  chosen  to  keep  consistent  with  other  previous  studies  performed  by 
PEG  IWS. 
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Type 

Assumption  or  Constraint  Description 

Assrrmption 

Travel  costs:  CONUS:  $2,500  /wk.,  OCONUS:  $5,000  /wk.  This  vahre 
is  consistent  with  previorrs  studies  performed  by  PEO  IWS. 

Assumption 

Data  rates  to/fr  om  the  installed  platform  are  boimded  between  2Mbps  to 

4  Mbps,  given  cirnent  satellite  cormuimication  (SATCOM)  bandwidth 
liuritations. 

Assrrmption 

Mirlti-tiered  technical  support  shall  follow  the  existing  USN  hierarchy: 
Tier  1  -  On-board  Srrpport 

Tier  2  -  Regional  Maintenance  Center  (RMC) 

Tier  3  —  In-Serwice  Engmeermg  Agent  (ISEA) 

Tier  4  -  Original  Equipment  Manufactmer  (OEM) 

Assumption 

The  mauirfactming  base  of  key  system  parts,  assemblies,  subsystems, 
components,  and  LRUs  are  not  stable  and  will  diminish  over  time. 

E.  ANALYSIS  APPROACH 

This  section  describes  the  systems  engineering  and  management  approach.  It 
elaborates  on  the  design  team  stnictme,  the  stakeholder  and  project  sponsors,  as  well  as 
technical  approach  and  methodology  used  for  this  capstone  report. 

1.  Design  Team  Structure 

The  capstone  team  was  comprised  of  six  students  from  the  Naval  Siuface  Warfare 
Center,  Port  Hrteneme  Division  (NSWC  PHD).  The  team  members  had  multidisciplinary 
backgrormds  from  laud  attack,  littoral,  and  air  defense  combat  and  weapon  systems,  and 
edircational  backgroimds  in  applied  mathematics,  architectiue,  mechanical,  comprrter, 
software,  network,  and  electronic  engineering  with  system  life-cycle  experience  in 
acquisition,  test  arrd  evahratiorr,  modernization,  ship  installation,  and  in-service 
engineering.  Table  2  lists  the  individiral’s  names,  roles,  and  responsibilities.  The  teams 
roles  are  indicated,  delineating  primar'y  responsibility  and  lead  effort  of  the  capstorre 
sirbject  matter  areas;  however,  all  team  members  were  involved  in  all  areas  of  the 
capstorre  report. 
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Table  2.  Team  Member  Roles  and  Responsibilities 


Team 

Member 

Roles 

Responsibilities 

Matthew 

Sheehan 

Project  CO 

Enteiprise 

Architect 

Sirperwised  and  lead  the  overall  project  effort  inchrding: 
selection  of  the  team  member  responsibilities,  team 
conflict  resohrtion,  provided  team  weekly  statirs  and  IPR 
briefings,  coordinated  external  sirpport,  schedrrled 
external  meetings  with  capstone  advisors  and 
programmatic  tasks  as  necessary. 

Collaborated  with  stakeholders,  leadership,  and  sirbject 
matter  experts,  to  birild,  formirlate,  and  align  the  project 
design  in  all  aspects.  These  inchrded,  birt  were  not  linrited 
to:  strategy,  process,  information,  technology,  design, 
logistics,  mission,  and  project  vision. 

Socrates 

Frangis 

Project  XO 

Software 

Lead 

Served  as  a  backirp  to  the  Project  CO  and  ensiued  the 
team  met  CO  expectations,  schedrrled  internal  team 
meetings,  and  managed  risk. 

Ensiued  logical  interface  design  of  HEL  DS  requirements, 
captiued  necessary  open  architectirre  message  types, 
proper  software  integration  with  HEL  system,  formatted 
for  remote  tr  oubleshooting  and  off  board  transfer. 
Performed  cost  estimation  on  DSHEL. 

Bridget 

Editor  In 

Ensmed  overall  documentation  contained:  relevant 

Giajeda 

Chief 

content,  proper  grammar,  corxect  spelling,  consistent  flow 
and  style,  proper  citations,  and  all  other  formatting 
necessary  for  capstone  and  thesis  compliance. 

Virginia 

Hardware 

Provided  requirement  analysis  based  on  component 

Shields 

Lead 

Secretary  of 
Notes 

engineering  drawing  designs,  physical,  mechanical, 
material,  and  weiglit  considerations. 

Captiued  minutes  and  action  items  diuing  team  meetings. 

Brian 

Architectirre 

Generated  the  fimctional  architecture  for  DSHEL,  which 

Meadows 

Desigrr 

Lead 

included  the  generation  of  infiastnicture  requirements  and 
interface  design. 

DaiTon 

Baida 

M&S  Lead 

Generated  M&S  efforl  of  ISEA  support  processes  (ciuieut 
HEL  without  DS  vs  HEL  with  DS). 

The  capstone  project  team  was  supported  by  NPS  advisors  for  guidance  and 
review  of  the  products  prior  to  submission.  Table  3  provides  the  advisor’s  names,  roles 
and  responsibilities  while  Figure  1  characterizes  the  overall  Team  Organizational 
Stnictme. 
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Table  3.  Advisor  Roles  and  Responsibilities 


Team  Member 

Roles 

Responsibilities 

Professor  Green 

Project  Advisor 

Provided  oversight  and  involvement  with:  all 
major  aspects  of  the  project  process,  review  of 
capstone  proposal,  the  development  of  the 
project  plan,  advising  project  execution, 
paiticipation  of  iu-progress  review  rehearsals, 
and  the  review  of  all  report  outputs  and  products. 

Professor  Nelson 

Project  Advisor 

Professor  Yoimg 

Project  Advisor 

Socrates 

Frangis 

-  XO&SWLead| 


Professor  Green 
ProfessorNelson 
Professor  Young 


Project  Aihrsors  ] 


Matthew 

Sheehan 


Project  CO  | 


I 


I 


Virginia 
Shields 

Hardware  Lead  | 


Bridget 
Grajeda 
J  Editor  in  Chief  I 


Brian 
Meadows 

Architecture  Lead  | 


Darron 

Baida 

s _ ,  Mod  &  Sim  Lead  I 


Figiue  1.  Team  Organizational  Stractiue 


2.  Stakeholder  and  Project  Sponsors 

The  capstone  team  solicited  inputs  from  stakeholders  regarding  challenges  and 
necessary  capabilities  critical  to  the  iu-seivice  sustainment  of  HEL  through  the  use  of  DS 
by  means  of:  customer  requirements,  thresholds,  objectives,  and  weighted  importance  for 
prioritization.  Coumiimication  chamiels  with  the  stakeholders  were  initially  deteimined 
by  local  project  advisors  within  the  dhected  energy  commimity.  Wliile  all  stakeholders’ 
inputs  were  important,  some  were  active  in  the  decision  process  and  had  duect  input, 
whereas  others  were  passive  and  dictated  requirements  and  capabilities  through  means  of 
naval  instmctions  and  enterprise  objectives.  Stakeholders  did  transition  between  the 
states  of  active  and  passive  throughout  the  life  cycle  of  the  project;  however.  Table  4 
cap  tines  then  predominant  inputs. 
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Table  4.  Stakeholder  Inputs 


Stakeholder 

Category 

Naval  Postgradirate  School  (NPS) 

Active 

PMS  405  -  Duected  Energy  and  Electric  Weapon  Systems  Program  Office 

Active 

Office  of  Naval  Research  (ONR) 

Passive 

NSWC  PHD  -  Office  of  Engineering  and  Technology  (OET) 

Active 

NSWC  PHD  -  Distance  Sirpport  Advocacy  Office 

Active 

Naval  Network  Operations  Center  (NOC) 

Passive 

Naval  Sea  Systems  Cormnand  (NAVSEA) 

Active 

Warfiglrter,  USN 

Active 

3.  System  Engineering  Process 

The  capstone  team’s  approach  was  based  on  the  systems  engineering  “V”  model. 
The  V  Model  is  a  way  of  visually  describing  the  fiuidamental  portions  of  systems 
engineering.  The  use  of  the  V  gives  a  depiction  of  the  flow  of  work  in  the  SE  model.  The 
V  is  used  to  give  a  stiuctmed  flow  from  defining  requirements  (system  and  performance) 
and  moving  into  design  before  testing.  Tliis  takes  the  project  through  a  logical  high  level 
order  that  keeps  in  mind  the  need  for  the  major  milestones  of  defining  the  goal  of  the 
system,  iteratively  designing  and  testing  it,  and  then  planning  for  the  practical  use  of  the 
system.  The  V  model  reinforces  the  key  areas  of  “verification  and  validation.”  Following 
the  V  forces  a  systems  engineer  to  constantly  and  cyclically  re-test  and  re-evahrate  the 
system. 

The  two  major  halves  of  the  V  model  represent  the  initial  portion  of  the  design 
called  “project  definition”  and  “project  test  and  integration.”  Both  of  these  were  irsed  in 
the  DSHEL  capstone  and  are  detailed  in  Figiue  2.  The  first  half  of  the  V  is  where  the 
system  engineers/designers  must  clearly  state  the  pmpose  and  reqirirements  of  the 
system/project  to  be  designed.  The  second  half  is  where  the  testing,  validation  and 
verification,  and  integration  take  place.  These  two  halves  of  the  model  are  constarrtly 
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repeated  and  re-worked  through  the  “verification  and  validation”  portion  of  the  V.  In 
Chapter  I,  the  concept  of  operations  (CONOPS)  and  background  of  the  DSHEL  system 
are  defined;  this  would  fall  in  the  beginning  portion  of  the  first  half  of  the  V  model. 
Chapter  II  identifies  stakeholder  needs,  develops  a  generic  distance  support  framework, 
and  includes  the  literature  review.  Chapter  III  captures  applies  the  distance  support 
framework  created,  as  well  as  detailing  the  functional  and  performance  requirements, 
KPPs,  KSAs,  MOEs  and  MOPs.  Chapter  IV  brings  the  system  through  concept  definition 
to  architecture  and  interface  design.  Chapter  V  employs  M&S  techniques  and  uses  the 
second  half  of  the  V  model.  Chapter  VI  analyzes  cost  and  risk  which  further  follows  the 
second  half  of  the  V.  The  final  chapter  (VII)  provides  the  project’s  technical  conclusions, 
recommendations  and  contributions  to  the  SE  BoK. 


Verification  and 


Eigure  2.  System  Engineering  V  Model  (from  Eclipse  Eoundation  2014) 


F.  SUMMARY 

By  applying  consummate  SE  judgment  and  rigor,  leveraging  emerging 
technologies,  and  applying  lessons  learned  from  traditional  DS  practices,  a  proactive  and 
robust  solutions  were  found  with  DSHEL.  The  efforts  detailed  above  show  an  increase  in 
availability  while  decreasing  the  life-cycle  cost  of  the  system. 
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II.  STAKEHOLDER  NEEDS  ANALYSIS 


A.  LITERATURE  REVIEW 

The  following  sections  detail  the  various  topics  researched  for  further  information 
in  order  to  understand  the  existing  BoK  in  scope  and  depth  concerning  DS.  Figure  3 
shows  the  literature  review  methodology  used  while  researching  DS  for  the  HEL.  Due  to 
DS  being  a  very  general  and  overarching  topic,  the  literature  review  for  DSHEL  was 
divided  into  two  additional  focus  areas.  The  material  reviewed  and  research  that  could  be 
attributed  directly  to  the  topic  of  DSHEE  was  categorized  under  the  “Explicit  Area.”  This 
area  is  reserved  for  all  things  related  to  DS.  The  second  division,  “Implicit  Area,”  was 
reserved  for  all  topics  that  were  important  factors  contributing  to  DSHEE,  but  was  not 
directly  related  to  it.  This  was  done  to  compensate  for  all  the  specific  and  unique  policies, 
procedures,  standards,  and  requirements  levied  on  DOD  programs  by  government 
organizations.  The  topics  investigated  were  selected  by  their  applicability  to  each 
research  area.  These  topics  were  then  analyzed  for  shortcomings,  which  validated  the 
need  for  an  integrated  DS  system  as  supported  by  a  framework  devoted  to  the  USN’s 
unique  needs. 


Topic 


Eigure  3.  Eiterature  Review  Methodology 
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1,  Explicit  Areas 

The  explicit  areas  (directly  related)  that  were  researched  and  reviewed  for 
DSHEL  analyzed  the  origins,  definitions,  key  theories,  concepts  and  ideas,  and  major 
issues,  as  well  as  the  main  questions  and  problems  that  have  been  addressed  to  date  on 
this  topic. 


a.  Distance  Support  Beginnings 

The  concept  of  DS  dates  back  to  advent  of  the  industrial  revolution  (1760-1840). 
The  creation  of  heavy  manufacturing  machinery  created  the  need  to  have  skilled 
repairmen  make  routine  site  visits  due  to  the  inability  to  transport  broken  machinery 
(Snider,  2011).  As  technology  progressed,  the  term  DS  did  as  well.  The  invention  of  the 
telephone  in  1876  would  have  a  profound  impact  on  how  DS  was  executed.  The  ability  to 
connect  customers/users  with  service  providers  in  real-time  allowed  for  a  greater 
exchange  in  knowledge  and  troubleshooting  techniques  resulting  in  reduced  downtimes. 
The  result  of  these  reduced  downtimes  was  an  increase  in  customer  satisfaction  and 
loyalty  which  lead  to  increased  profits  (Qui  and  Lee,  2015).  The  1960s  saw  the  birth  of 
the  modem  call  center,  a  single  point  of  contact  for  corporations  to  handle  customer 
queries,  complaints,  and  provide  support  services  (Hegde,  Sandeep,  and  Vasudeo  2012, 
58).  Call  centers,  now  known  as  help  desks,  proved  to  be  a  valuable  tool  to  connect 
customer  desires  with  service  providers.  Another  major  development  in  DS  was  AT&T’s 
creation  of  the  1-800  numbers  in  1968  when  a  U.S.  federal  judge  ordered  Ford  Motor 
Company  to  establish  a  free  phone  line  to  assist  customers  in  the  recall  of  a  faulty  car 
(Hegde,  Sandeep,  and  Vasudeo  2012,  60).  This  allowed  for  companies  to  have  a  direct, 
dedicated  line  to  provide  support  to  their  customers.  With  a  single-point  contact  number 
to  a  service  provider,  corporations  were  now  faced  with  the  task  of  organizing  and 
distributing  different  customer  requests  to  the  proper  service  expert.  This  issue  was 
resolved  with  the  creation  of  the  phone  menu  and  multi-tiered  technical  support.  A  phone 
menu  is  an  automated  menu  that  a  customer  dials  to  navigate  down  to  the  desired 
information  on  a  particular  topic.  Figure  4  gives  a  simple  pictorial  of  how  phone  menu 
number  selection  might  be  organized.  A  customer  with  an  inquiry  or  issues  calls  the 
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appropriate  service  line.  Companies  tend  to  have  one  service  number  to  cut  down 
customer  confusion  on  which  number  to  contact  concerning  topic  desire.  The  customer  is 
then  greeted  by  an  automated  menu  selection.  Referring  to  Figure  4,  the  customer  is 
presented  with  three  menu  options  as  noted  by  the  numbers  “1,”  “2,”  and  “3.”  Each  of 
these  numbers  would  be  linked  to  different  product  topic  areas,  lines,  or  business 
functions.  For  example,  selecting  number  “1”  may  connect  the  customer  to  a  general 
information  line,  where  selecting  number  “2”  may  connect  the  customer  to  a  billing  and 
accounting  department.  For  companies  that  have  many  product  lines  or  business 
functions,  a  nested  menu  may  be  employed.  Selecting  number  “3”  would  prompt  the 
customer  with  another  menu  offering  further  choices  from  which  to  select,  which  in  turn 
would  connect  the  customer  to  the  desired  product  line  or  business  function. 


Figure  4.  Phone  Menu  with  Nested  Menu  Example  (Icons  from  Flaticon  2014) 


The  use  of  nested  menus  is  important  in  reduced  customer  search  times  for 

connection  to  support.  If  a  phone  menu  used  a  linear  array  menu  system  (all  phone  menu 

selections  being  sequential),  a  customer  would  be  forced  to  sit  and  listen  to  each  option 
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until  hearing  the  selection  needed.  While  this  wait  time  may  not  seem  very  long,  a  user 
searching  for  a  topic  X  among  n  selections  will,  on  average,  take  0(n)  time  (where  0(n) 
is  big  O  notation  that  describes  the  limiting  behavior  of  the  linear  function  when  n 
approaches  a  set  value  or  infinity).  The  use  of  a  nested  menu,  effectively  altering  the 
phone  menu  from  a  linear  array  to  a  tree,  will  shorten  search  time  to  0(log(n))  (where 
0(log(n))  is  big  O  notation  that  describes  the  limiting  behavior  of  the  tree  function  when 
n  approaches  a  set  value  or  infinity).  If  it  takes  five  seconds  to  listen  to  each  phone  menu 
option,  a  customer  could  be  on  the  phone  for  quite  some  time  before  navigating  to  the 
desired  product  line  or  business  function.  Figure  5  shows  average  phone  menu  wait  times 
as  given  by  phone  menu  layout  type  and  number  of  phone  menu  options. 


Multi-tiered  technical  support  is  a  system  used  to  organize  service  support 
dependent  on  customer  need,  level  of  support  required,  or  business  function  in  order  to 
provide  the  best  possible  service  in  the  most  efficient  time.  The  higher  the  tier  level,  the 
greater  the  quality  and  specificity  of  the  support  information  will  be.  Both  of  these 

developments,  if  deployed  and  executed  correctly,  lead  to  decreased  customer  service 
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wait  times  and  increased  service  provider  productivity.  Typically,  all  customer  service 
inquiries  are  routed  to  a  low  tier  level  for  initial  information  gathering  and  high-level 
investigation  as  shown  in  Figure  6  and  Figure  7.  Low-level  technical  support,  also  known 
as  tier  zero  or  tier  one,  tends  to  possess  broad  organizational  knowledge,  but  limited 
technical  insight.  This  tier  can  usually  only  resolve  basic  customer  service  questions  and 
relies  heavily  on  scripted  question/answer  flowchart  guides.  The  next  level  of  technical 
support,  also  known  as  tier  two,  is  directed  customer  service  issues  and  questions  that  the 
lower  tier  is  not  equipped  to  resolve.  At  this  level,  support  technicians  have  advanced 
skills  such  as  troubleshooting  and  analysis.  Customers  who  provide  support  for  their 
users  usually  require  this  level  of  support.  The  highest  level  of  support,  commonly  known 
as  tier  three,  is  connected  to  customers  by  lower  levels  of  technical  support  for  issues  that 
require  a  subject  matter  expert.  While  many  customer  service  issues  and  inquiries  do  not 
make  it  to  this  level,  the  ones  that  do  are  typically  from  customers  who  specialize  in  the 
research,  development,  or  back-end  operations  of  the  product  field.  If  customer  issues 
cannot  be  resolved  at  this  level  of  technical  support,  the  company  will  usually  work  with 
the  original  equipment  manufacturer  (OEM)  to  ensure  the  product  is  repaired  upon  new 
version  release. 
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Back/High-End  Support 

Research  &  Development  of  Solutions 

Subject  Matter  Experts 


Advanced  Troubleshooting 
Administrative  Level  Support 
Advanced  Analysis  Methods 


General  Information 
Basic  Customer  Issues 
Universal  Support 


Expert 


Tier  3 


Tier  2 


Tier  1 


General 


Figure  6.  Multi-Tiered  Teehnical  Support  Hierarchy  Example 


Issue  Researched  Issue  Resolved 


Issue  Unresolved 


Issue  Researched  Issue  Resolved 
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Figure  7.  Multi-Level  Technical  Support  Information  Flow  (Icons  from  Flaticon 

2014) 
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Most  of  the  improvements  to  DS  have  been  to  the  serviee  provider  side  and  not 
the  platform  side.  The  birth  and  adoption  of  the  Internet  and  network  eonnected  devices 
changed  this  imbalance  of  improvement.  Customers  no  longer  have  to  call  the  OEM  for 
support.  Through  social  media  and  video  sharing,  customers  can  now  search  the  Internet 
for  technical  solutions  and  workarounds  for  their  products.  With  customers  becoming 
more  “self-sufficient”  in  providing  their  own  means  of  support,  drying  up  revenue 
streams  from  manufacture  service  support  calls,  product  manufacturers  focused  on 
cutting  product  cost  and  improving  product  quality.  The  combination  of  the  users  being 
“self-sufficient”  in  providing  their  own  technical  support  and  improving  product  quality 
lead  the  manufacturing  base  into  “hurting”  its  bottom  line  is  sales  figures.  A  solution  was 
created  that  effectively  killed  DS  for  all  “consumable”  goods:  planned  obsolescence. 
Planned  obsolescence  is  the  practice  of  designing-in  limited  life  use  into  a  product.  This 
forces  the  customer  to  purchase  a  new  product  after  a  predetermined  life  cycle  in  order  to 
generate  long  term  sales  volume  by  shortening  the  amount  of  time  for  a  customer  to  make 
repeated  product  purchases.  Figure  8  shows  a  standard  reliability-engineering  graph 
known  as  the  bathtub  curve.  The  bathtub  curve  is  used  to  show  the  failure  rate  of  the 
hazard  function.  The  three  parts  or  phases  of  the  hazard  function  are  as  follows: 

•  Burn  In — Shown  to  have  a  decreasing  failure  rate  due  to  initial  products 
failing  early,  typically  due  to  manufacturing  errors  or  poor  material  quality 

•  Useful  Life — Shown  to  have  a  constant  failure  rate  due  to  random  product 
population  losses 

•  Wear  Out — Shown  to  have  an  increasing  failure  rate  due  to  product 
degradation  of  use 
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Bum  In  Useful  Life  Wear  Out 


Time 

Figure  8.  Standard  Bathtub  Curve  (after  National  Institute  of  Standards  and 

Technology  2012) 

Planned  obsolescence,  as  shown  in  Figure  9,  artificially  shifts  the  wear  out  phase 
earlier.  This  does  not  necessarily  mean  that  the  product  itself  is  “worn  out.”  Artificial 
shifts  of  the  wear  out  phase  can  also  be  completed  by  inhibiting  or  removing  product 
capabilities  and  delaying  product  response  times. 
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Bum  In 


Useful  Life 


Wear  Out 


Figure  9.  Bathtub  Curve  with  Planned  Obsolescence 


b.  Modem  Distance  Support 

DS  today  varies  between  industries  and  within  an  industry  sector,  dependent  on 
product  cost  and  revenue  source.  In  industries  where  the  main  form  of  revenue  is  a 
service,  like  that  of  Internet  service  providers  (ISPs),  DS  is  initiated  and  conducted 
through  the  customer  or  service  user.  This  is  due  the  nature  of  the  business  model,  where 
the  platform  service  provider  owns  the  hardware  that  is  on  loan  to  the  customer  to 
facilitate  the  desired  service.  In  industries  where  that  main  form  of  revenue  is  the  product, 
like  that  of  vehicle  manufacturers  and  electronics,  DS  is  a  combination  of  customer 
inputs  and  product  feedback.  The  degree  and  detail  of  product  feedback  designed  into  the 
product  depends  on  the  product’s  and  customer’s  opportunity  cost.  In  many  cases,  low 
value  items  are  deemed  to  be  “consumable”  with  a  lifespan  of  only  three  to  four  years. 
These  items  are  often  replaced  outright  with  no  repair  or  internal  product  feedback,  such 
as  sensors,  designed-in.  Fligh  value  items,  such  as  aircraft  engines,  have  multiple  sensors 
designed  into  them  to  monitor  the  health  of  the  product  and  help  avoid  costly  repairs  or 
expensive  replacement.  These  products  have  a  much  longer  life  cycle  than  that  of  the 
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“consumable”  genre.  The  widespread  use  of  sensors  in  platform  systems  is  predieted  to 
transform  the  way  DS  is  performed  and  lead  to  a  “Third  Industrial  Revolution”  (Gerard 
Meijer  2008,  6).  With  the  use  of  sensorization  (the  aet  of  adding  sensors  to  a  deviee),  data 
ean  be  eolleeted  readily  and  analyzed  to  provide  a  greater  degree  of  DS  in  moving  from 
the  eurrent  reaetive  methods  to  that  of  proaetive  methods.  It  should  be  noted  that  this  area 
of  performing  DS  is  in  its  infant  stages.  Prognostie  and  “expert  systems”  are  still  being 
researeh  and  formalized  (IEEE  2014).  The  sensorization  of  produets  allows  DS  to  be 
performed  without  user  initiation  and  even  limited  user  involvement.  Examples  inelude 
the  OnStar™  serviee,  Eormula  One  raeing,  and  spaee  programs.  These  examples  all  have 
the  ability  to  remotely  monitor  system  symptoms  and  diagnose  the  issue  at  hand. 

c.  USN  Distance  Support 

DS  within  the  USN  has  historieally  lagged  behind  industry  (Modigliani  2014). 
This  is  not  beeause  DS  is  not  a  priority,  but  beeause  of  the  way  in  whieh  the  armed 
serviees  aequired  systems.  Consumer  deviees  tend  to  be  small,  assessable,  low  eost, 
replaeeable,  lightweight,  network  independent  and  non-mission  oritieal.  However, 
deviees  found  in  the  Eleet  are  the  opposite.  These  deviees,  sueh  as  a  missile  launeher,  are 
often  far  away  and  unable  to  make  port  to  eonduet  eorreetive  maintenanee.  Additionally, 
naval  systems  have  far  longer  useful  serviee  lives  than  eonsumer  deviees.  A  system  may 
remain  funetional  in  the  Eleet  long  after  many  subeomponents  are  no  longer  in 
produetion.  They  are  also  one-of-a-kind,  and  thus  eannot  be  easily  replaeed  or 
manufaetured  due  to  the  lead  times  and  proprietary  designs  used  by  eontraetors.  This 
ereates  a  unique  eapability  gap  when  trying  to  find  a  viable  solution  to  support  the  USN 
and  its  exelusive  requirements.  In  addition  to  these  unique  requirements,  the  USN  used  to 
design  and  require  systems  to  be  eertified  aeeording  to  their  various  standards  and 
speeifieations.  These  were  known  as  MIE-HDBK,  MIE-SPEC,  MIL-STD,  MIL-PRF,  and 
MIE-DTE.  Eaeh  of  these  standards  and  speeifieations,  nearly  45,500,  had  to  be  followed 
by  any  system  aequired  by  the  DOD.  These  stringent  requirements,  imposed  upon 
systems,  raised  unit  eosts  and  impeded  the  adoption  of  eutting  edge  teehnology.  To 
eombat  this,  the  Seeretary  of  Defense  William  J.  Perry  issued  a  memorandum  in  1994 
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that  changed  the  DOD’s  stanee  on  using  military  standards  and  speeifications  to  that  in 
favor  of  using  industry  standards  and  increasing  aeeess  to  “commercial  state-of-the-art 
teehnology”  (Perry  1994). 

Since  the  adoption  of  the  poliey,  the  USN  has  seen  an  explosive  growth  in  the 
fielding  of  eommercial  off-the-shelf  (COTS)  products.  Many  of  the  products  have  some 
limited  sensor  eapability  already  designed-in  whieh  the  USN  is  trying  to  take  advantage 
of  The  main  roadbloeks  in  using  these  additional  COTS  tools  are  the  laek  of  frameworks, 
organizations,  infrastructures  in  place,  and  integration  costs  or  a  combination  of  the 
aforementioned. 

A  reeent  paper  by  Nieolas  Guertin,  PEO-IWS  and  Paul  Bruhns,  ManTeeh 
International  Corp.  “Comparing  Aequisition  Strategies:  Maintenance  Free  Operating 
Period  (MFOP)  vs.  Traditional  Fogistics  Support”  contained  some  interesting  data  about 
eost  savings  realized  through  the  use  of  DS.  In  their  discussion  of  implementing  MFOP 
for  existing  systems  in  a  stepwise  manner,  they  state: 

The  first  step  is  to  capture  the  value  of  distance  support  from  ship  to  shore 
through  a  network  eonneetion  that  bridges  between  the  operational  system 
maintainers  (O)  to  intermediate  subject  matter  experts  and  tech  assist  (I) 
levels.  This  0-to-I  Fevel  Maintenanee  Bridge  requires  little  produet 
integration  and  will  immediately  generate  cost  savings.  Table  5  highlights 
an  example  program  that  achieved  a  15:1  cost  savings  ratio  when 
employing  distanee  support  serviees  over  deploying  teeh  assets: 
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Table  5.  FLEET  Teclmical  Assist  Data 


FLEET  Technical  Assist  Data  for  Submarine  Enterprise 


120  Fleet  Technical  Assist  (FTA)  Events  Performed 
93  Local  (Norfolk) 

27  Out-of-Aiea 


100%  Distance  Support  (DS)  Attempts  (CFFC/Command  Policy) 
16%  Success  Rate  Overall  on  All  FTA  Events 
37%  Success  Rate  on  Out-of-Area  Events 


Average  Man  Hours  (MH)  per  Event 
19MHvia  DS 

164  MH  via  On-Site  Support 

Average  Cost  per  Event  (Based  on  S60.00  per  Hour) 

$1,140.00  for  DS 

$9,840.00  Labor  and  $5,500.00  Travel  for  On-Site  ($15,390.00) 


Tliese  methods  generated  faster  response  time  for  solving  the  system 
problem,  as  well  as  lowering  labor  and  travel  costs  (from  Gueitin  and 
Biuhns  2011). 

The  DS  for  the  HEL  capstone  project  is  an  m  depth  SE  analysis  and  M&S  of  a  DS 
system  designed  for  a  generic  HEL  weapons  system.  After  the  initial  prociu  ement  of  the 
HEL,  the  USN  must  provide  operation  and  support  (O&S)  fimds,  at  approximately  60- 
80%  of  the  total  life  cycle  of  the  system  (Defense  Acqirisition  University  2011).  This 
capstone  explored  the  theory  that  providing  DS  will  lead  to  a  lower  total  ownersliip  cost 
of  the  HEL  system.  Through  M&S  the  goal  of  the  project  was  to  prove  this.  The  project 
considered  pre-existing  work  on  DS,  sirch  as  the  Six  Pillars  of  DS.  The  Six  Pillars  of  DS, 
as  depicted  in  Figirre  10,  consist  of;  Remote  Tech  Assist,  Remote  Diagnostics,  Remote 
Repan/V alidation.  Remote  Monitoring,  ePrognostics,  and  Self-Repau/Healing.  Using  SE 
methodologies,  the  team  looked  at  a  sirbset  of  the  Six  Pillars,  focirsing  on;  Remote  Tech 
Assist,  Remote  Diagnostics,  Remote  Monitoring  and  Remote  Repau/V alidation. 
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Figure  10.  Distance  Support  Functional  Capabilities 


According  to  the  Navy  Distance  Support  policy  written  and  signed  out  in  March 
of2007, 

Distance  support  is  a  Navy  Enterprise  effort  that  combines  people  (e.g., 
subject  matter  experts),  processes  (e.g.,  remote  equipment  monitoring, 
tele-medicine,  interactive  detailing,  etc.),  and  technology  (e.g.,  data 
compression  and  replication)  into  a  collaborative  infrastructure  without 
regard  to  geographic  location.  Distance  support,  at  a  minimum,  includes 
the  functional  area  of  logistics;  maintenance  and  modernization; 
Manpower,  Personnel,  Training,  and  Education  (MPT&E);  and  medical 
support.  Distance  support  remotely  projects  reactive,  proactive,  and 
predictive  support  to  Sailors  across  these  functional  areas,  in  order  to 
achieve  the  right  readiness  at  the  right  time,  at  the  right  cost.  Effective  and 
reliable  information  transfer  is  a  key  prerequisite  to  enable  Distance 
Support  capabilities  and  processes.  (Chief  of  Naval  Operations  2007,  2) 

This  is  a  very  broad  concept  spanning  multiple  disciplines  and  practices  within 
the  USN  enterprise.  The  capstone  was  specifically  interested  in  how  certain  DS  concepts 
can  be  applied  to  the  HEE  weapons  system  and,  possibly,  combat  systems  in  general  for 
the  USN.  By  narrowing  the  scope  of  DS  in  this  manner  the  discussion  can  focus  on  the 
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concept  of  providing  a  DS  capability  for  the  HEL  system.  Providing  a  eapability  refers  to 
the  ability  of  the  ISEA  to  provide  remote  teehnieal  assistanee  to  the  system.  Speeifieally, 
DS  eneompasses  the  ability  to  resolve  issues  without  travel,  monitor  issues  remotely, 
troubleshoot  and  repair  remotely,  and  the  ability  to  anticipate  and  predict  issues  before 
oeeurrenee.  It  is  for  this  reason  that  the  EISN  has  developed  the  eoneept  of  Six  Pillars. 
These  pillars  span  between  reaetive  and  proactive  methods  of  DS  teehnieal  assistanee. 
The  benefits  and  limitations  of  eaeh  of  these  areas  were  eovered  in  depth. 

(1)  Reactive  Methods 

Reaetive  DS  is  defined  as  “after  the  oeeurrenee  response”  (Naval  Surfaee  Warfare 
Center,  Port  Hueneme  Division  2013).  The  following  methods  fall  into  this  eategory: 
Remote  Teehnieal  Assistanee,  Remote  Diagnostics,  and  Remote  Repair  and  Validation. 
All  of  these  methods  were  implementable  to  date  with  eurrent  COTS  technologies. 

(a)  Remote  Technical  Assistance 

Remote  Technical  Assistance  is  the  ability  to  resolve  maintenanee  support  issues 
without  travel  using  tools  such  as  Sailor  to  Engineer,  Sailor  2.0,  email,  ehat  and  phone 
(Naval  Surface  Warfare  Center,  Port  Hueneme  Division  2013).  Most  of  the  teehnieal 
assistanee  provided  to  the  USN  still  eomes  in  this  from.  The  benefit  to  this  form  of 
teehnieal  assistanee  is  that  it  is  low  eost,  pervasive,  and  well  understood.  Email  is 
eommon  within  the  USN,  and  the  sailors  have  a  direet  line  of  eommunieation  to  the 
engineer  in  many  eases.  Additionally,  in  many  eritieal  weapons  systems,  the  ISEA 
partieipates  in  group  ehat  with  the  ships  to  provide  assistanee  as  needed,  websites  have 
been  ereated  to  help  provide  readily  available  teehnieal  information  to  the  sailor  as  well 
as  forum  support  to  resolve  issues  that  eome  up.  All  of  these  tools  are  in  use  today  in  the 
USN. 

One  of  the  big  issues  with  Remote  Teehnieal  Assistanee  methods  explained  above 
is  that  they  are  temporal.  As  time  progresses,  information  beeomes  stale  and  less  relevant. 
Two  examples  to  demonstrate  this  prineiple  as  it  oecurs  today  in  the  USN  are  diseussed. 
Eirst  is  the  eoneept  of  email;  while  email  is  eheap  to  set  up  and  relatively  well 
understood,  it  is  difficult  to  use  as  a  tool  for  capturing  technical  information.  Eimitations 
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to  email  include:  overall  file  size  and  communication  transmission  delay.  Limited  file 
size  inhibits  the  amount  of  information  that  can  be  provided  to  the  sailor  to  resolve  an 
issue.  Communication  transmission  delay  can  span  weeks  to  months  as  the  accumulated 
time  between  email  transmissions  grows.  This  is  because  email  is  time  dependent.  If  the 
ship  receiving  support  is  in  a  different  time  zone  than  the  shore  based  site,  the  time  to 
answer  email  becomes  longer.  Additionally,  the  bandwidth  on  ships  for  email  is 
constrained,  especially  when  the  ship  is  underway.  Once  the  engineer  has  successfully 
provided  support  to  the  ship,  the  solution  may  be  logged  to  use  in  future  support  events. 
Unfortunately,  these  solutions  are  not  being  stored  in  a  central  location  to  facilitate 
knowledge  management  and  sharing  between  technical  support  groups. 

The  next  example  concerns  the  use  of  websites  within  the  USN  for  support.  There 
exist  a  plethora  of  support  websites  that  have  been  created  for  use  by  the  Fleet.  Each 
website  is  created  and  populated  with  information  to  help  the  sailors  better  execute  their 
duties  and  resolve  issues  with  their  system  in  a  timely  manner.  The  problem  with 
websites  is  that  while  they  are  cheap  to  create;  they  are  costly  to  maintain  and  require 
constant  updates  to  information.  Also,  on-line  technical  support  resources  are  poorly 
advertised. 

Both  of  these  examples  paint  a  challenging  view  of  the  remote  technical 
assistance  methods  of  DS.  These  examples  illustrate  that  while  email,  websites,  and  chat 
programs  are  prevalent  and  widespread  in  terms  of  use,  they  are  limited  as  a  means  of 
resolving  issues  within  weapons  systems. 

(b)  Remote  Diagnostics 

Remote  Diagnostics  is  the  ability  to  establish  remote  connectivity  to  observe,  and 
diagnose  system  performance  in  a  manner  similar  to  the  engineer  being  on-site  (Naval 
Surface  Warfare  Center,  Port  Hueneme  Division  2013).  This  method  of  DS  is  not  as 
pervasive  in  the  USN  ecosystem  because  to  tap  into  this  method  of  DS,  the  system 
onboard  the  ship  must  have  a  passive  connection  to  shore  via  the  Global  Information  Grid 
(GIG).  Typically,  weapons  systems  do  not  have  a  direct  connection  to  the  GIG  as  this 
would  change  the  cybersecurity  posture  of  the  system.  However,  aboard  ships  there  are 
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certain  systems  that  are  taetieal  in  nature,  but  are  eritieal  enough  to  warrant  remote 
diagnosties.  One  sueh  example  of  this  is  the  AEGIS  weapons  system.  Due  to  the  eritieal 
nature  of  this  weapons  system,  the  system  itself  has  a  subsystem  known  as  the 
Operational  Readiness  Test  System  (ORTS).  This  system  is  responsible  for  performing  a 
variety  of  diagnosties  on  the  AEGIS  eombat  system  to  determine  its  overall  readiness. 
Due  to  the  mission  eriticality  of  test  results  produced  by  ORTS,  Naval  Surfaee  Warfare 
Center,  Port  Hueneme  Division  (NSWC  PHD)  developed  a  ship  based  system  eall  the 
Operational  Readiness  Test  Systems  Teehnieal  Assistanee  Remote  Support 
(ORTSTARS).  ORTSTARS  has  been  sueeessful  in  allowing  engineers  to  log  into  the 
AEGIS  eombat  system  on  a  ship  and  diagnose  problems  from  shore.  All  of  this  is  done 
using  a  secure  conneetion.  This  capability  offers  the  ability  to: 

•  assist  with  fault  detection 

•  isolate  faults 

•  perform  intermediate  maintenanee 

•  eorreet  faults 

This  method  of  DS  does  not  suffer  from  the  same  time  delay  issues  that  are  seen 
with  traditional  teehnieal  assistance  via  email.  However,  Remote  Diagnosties  is  not 
without  its  faults.  One  of  the  issues  is  that  the  information  gathered  has  to  be  done 
manually,  which  is  time  intensive.  Some  ORTSTARS  sessions  with  ships  ean  be  as  long 
as  eight  hours  depending  on  the  speed  of  the  connection  and  the  loeation  of  the  ship.  The 
eonneetion  may  drop  unexpectedly  eausing  the  session  to  be  reestablished. 

ORTSTARS  does  not  control  the  pipe  to  whieh  they  eonnect  off  of  ship.  This 
means  that  elose  eoordination  must  be  maintained  with  Spaee  and  Naval  Warfare 
Systems  Command  (SPAWAR)  through  the  use  of  a  memorandum  of  agreement  (MOA). 
These  MO  As  allow  bidireetional  flow  of  information  on/off  ship  and  allow  eonneetions 
through  the  shipboard  firewalls.  Despite  these  shorteomings.  Remote  Diagnosties  is  an 
improvement  on  the  traditional  teehnieal  assistance  methods  of  email  and  ehat. 
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(c)  Remote  Repair  and  Validation 

Remote  Repair  and  Validation  refers  to  the  ability  to  remotely  re-configure  a 
system  to  correet  problems  (Naval  Surfaee  Warfare  Center,  Port  Hueneme  Division 
2013).  This  method  of  DS  requires  not  only  a  direet  conneetion  to  the  system,  but  it  also 
requires  active  coordination  of  ship’s  force.  Unlike  Remote  Diagnostics,  where  the 
connection  to  the  shipboard  system  is  passive  in  nature.  Remote  Repair  and  Validation  is 
an  active  form  of  DS.  The  engineer  on  shore  has  an  active  connection  to  the  system  on 
board  ship.  During  this  active  connection,  the  user  has  the  ability  to  make  changes  to  the 
system  to  resolve  and  correct  faults.  This  is  done  to  provide  corrective  actions  to  well- 
known  and  established  faults  that  occur  in  the  system  which  have  an  approved  corrective 
action.  This  is  a  sensitive  process  when  dealing  with  mission  critical  systems  and  requires 
the  sailor  to  be  actively  monitoring  the  procedure  that  is  being  run  remotely.  This  active 
supervision  on  the  part  of  the  sailor  satisfies  the  “two  person  positive  control”  critical  to 
the  security  of  systems.  The  downside  to  this  method  of  DS  is  that  it  is  reactive  in  nature. 
Additionally,  it  requires  coordination  with  several  outside  agencies  to  establish  a  secure 
and  reliable  inbound  connection  to  the  ship.  There  are  several  layers  of  security  present  in 
the  GIG  that  must  be  changed  in  order  to  allow  this  type  of  connection  to  the  system. 

(2)  Proactive  Methods 

Proactive  DS  is  defined  as  “Remote  continuous  monitoring  and  corrective  action 
without  shipboard  personnel  interaction  response”  (Naval  Surface  Warfare  Center,  Port 
Hueneme  Division  2013).  The  following  methods  fall  into  this  category:  Remote 
Monitoring,  ePrognostics,  and  Self-Healing/Repair.  These  methods  require  more  effort  to 
fully  implement  and  are  not  completely  available  with  current  COTS  technologies. 

(a)  Remote  Monitoring 

Remote  Monitoring  is  the  first  method  of  DS  that  takes  a  proactive  approach  to 
DS  (Naval  Surface  Warfare  Center,  Port  Hueneme  Division  2013).  In  this  approach 
systems  are  monitored  from  the  shore  to  determine  if  there  is  a  fault  before  the  ship 
initiated  a  casualty  report  (CASREP).  This  method  may  employ  the  use  of  a  monitoring 
system  on  the  ship  that  captures  simple  network  management  protocol  (SNMP) 
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information,  error  logs,  and  vulnerability  scan  data,  which  is  then  sent  off  ship  to  be 
analyzed  from  shore.  Remote  Monitoring  assumes  this  data  is  being  collected  and  piped 
off  ship  in  near  real-time.  A  typical  example  of  this  type  of  DS  is  the  monitoring  of  the 
network  traffic  coming  off  ship  by  the  network  operations  center  (NOC)  or  the 
monitoring  of  radar  transmit  power.  In  both  of  these  cases  the  information  is  sent  to  shore 
in  a  raw  data  format  that  the  engineers  analyze  to  determine  whether  the  system  is 
operating  within  prescribed  tolerances.  The  benefit  of  this  method  is  that  the  shore  based 
engineer  can  look  at  the  data  and  determine  whether  the  system  is  operating  correctly. 
Also,  this  does  not  require  the  participation  of  the  sailor  to  perform  this  analysis.  The 
downside  is  that  this  information  may  be  more  than  what  is  required  to  determine  the 
state  of  the  system,  additionally  the  cost  (i.e.,  the  network  bandwidth  overhead)  of 
performing  this  type  of  DS  methodology  may  be  too  high  to  implement  on  a  platform  that 
has  an  older  network  transport  layer  or  a  smaller  platform  that  does  not  have  a  large  pipe 
off  the  ship.  Although  this  method  is  very  useful  for  the  shore,  it  may  not  be  feasible  for 
every  system. 

(b)  ePrognostics 

This  method  of  DS  expands  on  the  previous  method  and  uses  the  idea  that  for 
certain  types  of  data  (especially  analog  data)  trends  can  be  established.  Various  stochastic 
methods  can  be  used  to  analyze  the  data  for  system  performance  and  can  then  trend  this 
data  over  time  to  establish  a  known  “good  baseline”  for  data.  Predictive  algorithms  can 
be  used  to  detect  when  a  certain  data  set  is  trending  outside  of  the  known  “good 
baseline.”  This  method  of  automated  DS  is  still  in  its  infancy  for  combat  system 
elements,  however,  for  many  hull,  mechanical,  and  electrical  (HM&E)  systems, 
prognostic  condition  based  maintenance  (CBM)  is  well  established. 

(c)  Self-Repair/Healing 

The  last  method  of  DS  is  analogous  to  what  is  known  as  an  “expert  system.”  An 
expert  system  is  a  computer  system  that  emulates  the  decision-making  ability  of  a  human 
expert  (Jackson  1998,  2).  The  system  is  fully  aware  of  its  inner  workings  as  well  as  its 
external  interfaces  and  dependencies.  Expert  systems  are  systems  that  have  little  to  no 
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need  of  human  assistance  in  the  event  of  failure  or  event  execution.  These  systems  have 
the  ability  to  self-govern  (redirect  resources  to  maintain  system  performance  during 
critical  operations)  and  sometimes  use  artificial  intelligence  (AI)  to  “learn”  from  previous 
events.  Expert  systems  have  the  distinct  advantage  in  needing  minimal  human  interaction 
to  right  functions,  but  these  systems  can  be  costly  to  implement  and  suffer  from  a  lack  of 
robust  resources  for  knowledge  acquisition  in  order  to  enable  AI  machine  learning. 

d.  Distance  Support  Frameworks 

Due  to  the  USN’s  unique  set  of  environmental,  security,  programmatic,  and 
organizational  requirements,  a  “plug-n-play”  DS  framework  does  not  exist.  The 
following  existing  frameworks  below  were  studied. 

(1)  Information  Technology  Infrastructure  Library 

Of  the  existing  frameworks  available,  the  Information  Technology  Infrastructure 
Library  (ITIL)  was  the  optimal  candidate  to  study  and  glean  best  practices.  ITIL  provides 
a  framework  of  best-practices  for  the  service  management  of  Information  Technology 
(IT)  products.  Much  like  the  purpose  of  DSHEL,  IT  services  and  data  have  become 
essential  to  business  operations  as  well  as  strategic  assets.  The  main  purpose  of  ITIL  is 
the  continual  measurement  and  improvement  of  the  quality  of  IT  services  delivered,  from 
both  a  business  and  a  customer’s  perspective  (AXELOS  Ltd.  2011,  14).  If  implemented 
and  executed  correctly,  ITIL  benefits  include: 

•  increased  user  and  customer  satisfaction  with  IT  services 

•  improved  service  availability,  directly  leading  to  increased  business  profits 
and  revenue 

•  financial  savings  from  reduced  rework  or  lost  time  and  from  improved 
resource  management  and  usage 

•  improved  time  to  market  for  new  products  and  services 

•  improved  decision-making  and  reduced  risk 

The  ITIL  framework  is  broken  down  into  five  associated  life-cycle  phases: 
Service  Strategy,  Service  Design,  Service  Transition,  Service  Operation,  and  Continual 
Service  Improvement  as  described  in  Ligure  1 1 . 
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Figure  11.  ITIL  Service  Life  cycle  (from  AXELOS  Ltd.  201 1,  7) 

Figure  12  illustrates  how  each  of  these  phases  is  made  up  of  sequential  steps  and 
processes  that  govern  and  align  each  life-cycle  stage  with  the  business  it  is  supporting. 
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Figure  12.  Integration  Aeross  the  Service  Life  Cycle  (from  AXELOS  Ltd.  2011,  9) 
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Each  of  these  phases  will  be  detailed  below. 


(a)  Service  Strategy 

The  serviee  strategy  sits  at  the  core  of  the  ITIL  framework.  This  is  due  to  the 
service  strategy  being  the  key  plan  in  providing  a  solution  to  the  business  problem  at 
hand.  The  service  strategy  is  developed  with  many  parties  in  order  to  ensure  it  meets  the 
needs  of  the  eustomers  and  users  of  the  business  problem.  These  needs  and  requirements 
are  the  foundation  in  whieh  the  service  strategy  is  built.  This  phase  also  builds 
understanding  among  stakeholders  in  answering:  (AXELOS  Etd.  2011,  13) 

•  What  is  a  service? 

•  What  services  should  be  offered? 

•  To  whom  the  services  should  be  offered? 

•  How  will  serviee  performance  be  measured? 

•  What  is  service  value  (utility  and  warranty)? 

•  What  are  the  service  provider  types? 

•  Are  there  eritical  suceess  factors? 

•  How  will  the  services  be  delivered? 

•  Who  plays  what  role  and  how? 

(b)  Service  Design 

Service  design  is  the  first  step  into  turning  the  service  strategy  into  a  tangible 
produet.  Service  design  involves  balancing  functionality  requirements  (service  utility), 
performance  requirements  (service  warranty),  resources  availability  and  timeseales 
(AXEEOS  Etd.  2011,  22).  As  these  areas  are  balaneed,  normally  with  the  use  of  eost  and 
risk  analysis,  a  holistic  solution  providing  end-to-end  quality  should  emerge.  An 
important  part  of  this  phase  is  the  creation  of  service  level  agreements  (SEAs).  A  SEA  is 
an  agreement  between  a  serviee  provider  and  an  end  user  (eustomer).  The  SLA  typically 
will  detail  the  service,  service  level  targets,  quality  of  service  (QoS),  and  the 
responsibilities  of  eaeh  party  involved  (AXELOS  Ltd.  2011,  25).  In  contrast  to  the  EISN 
DS  methods,  ITIL  has  differing  definitions  for  reaetive  and  proactive  activities. 
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•  Reactive  activities  are  monitoring,  measuring,  analysis  and  management  of 
events,  incidents  and  problems  involving  service  unavailability  (AXELOS 
Ltd.  2011,26) 

•  Proactive  activities  are  proactive  planning,  design,  recommendation  and 
improvement  of  availability  (AXELOS  Ltd.  2011,  26) 

In  addition  to  SLAs  being  created  in  this  phase,  information  security  management 
(ISM)  is  also  considered.  The  USN’s  cybersecurity  requirements  are  more  stringent  than 
ITIL,  but  both  do  share  a  set  of  common  terminology  and  service  management  activities 
that  were  applied. 

•  Availability  means  that  information  is  available  and  usable  when  required 
(AXELOS  Ltd.  2011,28). 

•  Confidentiality  means  that  information  is  observed  by  or  disclosed  to  only 
those  who  have  a  right  to  know  (AXELOS  Ltd.  2011,  28). 

•  Integrity  means  that  information  is  complete,  accurate  and  protected  against 
unauthorized  modification  (AXELOS  Ltd.  2011,  28). 

•  Authenticity  and  Non-repudiation  means  that  business  transactions,  as  well  as 
information  exchanges,  can  be  trusted  (AXELOS  Ltd.  2011,  28). 

(c)  Service  Transition 

Service  transition  ensures  new,  modified,  legacy,  or  retiring  services  meet  the 
expected  or  required  levels  of  capability  to  the  business  and  customer  as  the  service 
design  is  implemented  throughout  the  enterprise.  As  new  systems  come  online  and  older 
systems  are  taken  offline,  change  and  configuration  management  become  important 
supporting  processes  to  ensure  service  quality. 
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Figure  13.  Scope  of  Change  and  Release  Management  for  Services  (from  ITIL  2011, 
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Another  important  part  in  this  phase  is  the  execution  of  service  validation  and 
testing.  Once  the  new/old  systems  have  been  put/taken  on/off  line,  the  whole  service  is 
put  through  verification  and  validation  testing  to  ensure  that  no  degradation  to  service 
quality  has  occurred.  Figure  13  shows  the  interactions  and  interfaces  required  between 
the  parties  as  changes  are  made  at  differing  levels. 

(d)  Service  Operation 

This  phase  is  the  execution  of  the  service  design  and  transition  phases.  The 
service  is  delivered  to  business  and  customer  as  detailed  by  the  SLAs  created  in  the 
service  design  phase.  This  phase  not  only  provides  and  delivers  the  service,  but  also 
controls  events,  incidents,  requests,  problems,  access,  and  other  common  service 
operation  activities. 

(e)  Continual  Service  Improvement 

The  continual  service  improvement  phase,  as  shown  in  Figure  14,  is  the  feedback 

loop  into  the  first  phase  of  the  ITlL  framework,  service  strategy.  As  is  with  any  superior 
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service,  the  current  model  must  always  be  scrutinized  for  flaws,  inefficiencies,  gains, 
technological  improvements,  and  added  capability  in  order  to  continually  strive  to 
provide  higher  service  quality. 


Figure  14.  The  Continual  Service  Improvement  Approach  (from  ITIL  2011,  51) 
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Figure  15  shows  the  Seven-Step  Improvement  Process.  This  phase  is  also  where 
service  measurement  and  reporting  play  a  part  in  improving  future  service.  Monitoring 
and  measuring  aid  in  this  phase  by  (ITIL  201 1,  55): 

•  Validating  previous  decisions  that  have  been  made. 

•  Direct  activities  in  order  to  meet  set  targets. 

•  Justify  that  a  course  of  action  is  required,  with  factual  evidence  or  proof. 

•  Intervene  at  the  appropriate  point  and  take  corrective  action. 

Technology,  process,  and  service  metrics  also  aid  in  shedding  light  on  the  areas 
above.  Metrics  are  only  useful  if  an  established  baseline  has  been  created  beforehand. 

(2)  International  Organization  for  Standards  (ISO)/Intemational 
Electrotechnical  Commission  (lEC)  20000 

The  ISO/IEC  20000  is  a  Service  Management  System  (SMS)  standard.  This 
standard  is  a  combination  of,  and  allows  for  the  ITIL,  Microsoft  Operations  Eramework, 
and  Control  Objectives  for  Information  and  Related  Technology’s  (both  explained  further 
below)  IT  service  management  frameworks.  ISO/IEC  20000  consists  of  five  parts,  as 
shown  in  Eigure  16,  and  can  be  used  by  (ISO)  and  the  International  Electrotechnical 
Commission  (lEC)  2014): 

•  an  organization  seeking  services  from  service  providers  and  requiring 
assurance  that  their  service  requirements  will  be  fulfilled 

•  an  organization  that  requires  a  consistent  approach  by  all  its  service  providers, 
including  those  in  a  supply  chain 

•  a  service  provider  that  intends  to  demonstrate  its  capability  for  the  design, 
transition,  delivery  and  improvement  of  services  that  fulfill  service 
requirements 

•  a  service  provider  to  monitor,  measure  and  review  its  service  management 
processes  and  services 

•  a  service  provider  to  improve  the  design,  transition,  delivery  and  improvement 
of  services  through  the  effective  implementation  and  operation  of  the  SMS 

•  an  assessor  or  auditor  as  the  criteria  for  a  conformity  assessment  of  a  service 
provider’s  SMS  to  the  requirements  in  ISO/IEC  20000-1:201 1 
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Figure  16.  Service  Management  System  (from  International  Organization  for  Standardization  (ISO)  and  the  International 

Electrotechnical  Commission  (lEC)  2014) 
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The  ISO/IEC  20000  standard  has  a  lot  of  overlap  with  the  other  frameworks 
investigated,  but  was  useful  in  understanding  how  specifie  requirements  for  the  serviee 
provider  fulfill  agreed  service  requirements. 

(3)  Microsoft  Operations  Framework 

The  Microsoft  Operations  Framework  (MOF)  4.0  has  many  similarities  to  the 
ITIF  and  ISO/IFC  20000  standard  with  the  exception  that  it  has  a  slightly  different  life- 
cycle  foundation  layer  and  a  total  of  three  phases.  These  phases  are;  plan  phase,  deliver 
phase,  and  the  operate  phase  included  within  a  manage  layer. 
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Figure  17.  Structure  of  MOF  4.0  (from  Alexander  2008) 
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Figure  17  gives  a  more  detailed  view  into  the  MOF  4.0  layer  and  its  phases. 
While  this  framework  ean  be  readily  applied  to  other  software  vendor  produets,  the  MOF 
4.0  framework  is  mainly  geared  towards  Mierosoft  produets  and  serviees.  While  this 
framework  has  the  same  similarities  of  the  other  frameworks  mentioned  in  this  report,  the 
MOF  is  unique  in  breaking  apart  the  framework  into  seetions  that  are  serviced  by 
products.  In  analyzing  the  different  Microsoft  products  that  provide  these  services, 
DSHEL  was  able  to  mirror  a  similar  delineation  of  system  functions. 

(4)  Control  Objectives  for  Information  and  Related  Technology 

The  Control  Objectives  for  Information  and  Related  Technology  (COBIT) 
framework,  like  ITIL,  ISO/lEC  20000,  and  MOE  4.0  is  also  used  for  IT  management  and 
governance.  COBIT  is  different  from  the  previous  frameworks  in  that  it  is  centered  on  a 
number  of  principles,  areas  and  processes,  model  and  levels,  and  process  attributes.  The 
particular  pieces  of  information  to  note  from  COBIT  are  listed  below. 

(a)  Principles  of  Control  Objectives  for  Information  and  Related  Technology 

There  are  five  key  principles  for  IT  management  and  governance  that  COBIT 
follows.  They  are  (ISACA  2013): 

1 .  meeting  stakeholder  needs 

2.  covering  the  enterprise  end-to-end 

3.  applying  a  single  integrated  framework 

4.  enabling  a  holistic  approach 

5.  separating  governance  from  management 

(b)  Process  Capability  Model  and  Levels 

COBIT  uses  a  level  rank  system  in  defining  the  overall  maturity  of  process 
capabilities.  This  level  rank  system  is  of  particular  note  due  to  its  applicability  throughout 
this  capstone  in  establishing  baseline  maturity  levels  for  process  capability  models.  The 
capability  model  and  level  explanations  are  detailed  in  Table  6. 
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Table  6.  Process  Capability  Model  and  Levels  (from  ISACA  2013) 


Matuiiri’ 

Level 

Meaning 

Description 

Level  0 

hicomplete 

The  process  is  not  implemented  or  fails  to 
achieve  its  pmpose 

Level  1 

Perforaied  (Infonned) 

The  process  is  implemented  and  achieves  its 
pmpose 

Level  2 

Managed  (Planned  and 
monitored) 

The  process  is  managed  and  results  ar  e 
specified  controlled  and  maintained 

Level  3 

Estabhshed  (Well  defined) 

A  standard  process  is  defined  and  used 
throrrghout  the  organization 

Level  4 

Predictable 

(Qrrantitatively  nranaged) 

The  process  is  executed  consistently  witliin 
defined  limits 

Level  5 

Optimizing  (Continuous 
improvement) 

The  process  is  continrrously  improved  to  meet 
relevant  crurent  and  projected  business  goals 

e.  Platform  of  Interest — High  Energy  Laser 

In  response  to  Section  25 1  of  the  National  Defense  Authorization  Act  for  Fiscal 
Year'  (FY)  2000,  the  DOD  outlined  its  master  plan  to  capitalize  on  the  signifrcant 
advances  of  HEL  technology  in  support  of  emerging  national  secmity  needs  of  the  21st 
centiuy  (Department  of  Defense  2000).  The  reconunendations  comprised  a  restractiued 
perspective  in  developing  HEL  weapons.  Developing  revolutionary  capabilities  m  HEL 
weapons  required  a  coordinated  and  focitsed  investment  strategy  imder  a  new 
management  strnctrrre,  fea truing  a  Joint  Technology  Office  (JTO)  with  senior-level 
oversight  provided  by  a  technology  coimcil  and  board  of  directors.  A  better  balance  coitld 
be  achieved  by  transitioning  large  demonstration  projects  to  non-science  and  technology 
(S&T)  accoimts  sooner  than  had  been  done  m  the  past.  As  sirch,  the  DOD  focits  was  pirt 
to  three  major  HEL  system  types  for  S&T  exploration:  chemical  lasers  (CL),  solid  state 
lasers  (SSL),  and  free  electron  lasers  (FEL).  While  the  focus  of  DSHEL  is  on  the  near 
realization  of  SSL,  reqrruernents,  artifacts,  arcliitectiue,  methodologies,  and  analysis  were 
decoitpled  such  that  it  could  be  reirsed  on  FEL  or  CL. 


41 


There  have  already  been  diseussions  on  how  the  DOD  should  address  laser 
technology.  Some  of  the  key  areas  of  concern  that  are  discussed  in  “Report  of  the  High 
Energy  Laser  Executive  Review  Panel,  Department  of  Defense  Laser  Master  Plan,  March 
24,  2000,”  include  cost,  the  available  talent  pool,  and  the  structured  approach  of  how  one 
might  organize  the  developing  laser  technology  in  the  DOD.  This  organizational  plan 
cited  in  the  aforementioned  document,  uses  a  tiered  organizational  structure.  Technology 
Area  Working  Groups  are  comprised  of  members  from  “all  DOD  stakeholder 
organizations”  for  the  HEL.  This  group  in  turn  would  report  to  and  work  with  the  Joint 
Technology  Office  (JTO),  who  receives  oversight  from  a  senior  board  of  Directors  and 
the  Technology  Council.  Defense  Advanced  Research  Projects  Agency  (DARPA)  and 
Ballistic  Missile  Defense  Organization  (BMDO)  are  also  included  for  collaboration.  This 
allows  for  different  perspectives  and  insights.  While  the  large  knowledge  base  would  be 
beneficial,  it  may  also  cause  difficulties  as  it  could  turn  into  a  situation  of  having  too 
many  differing  agendas  and  directions,  with  a  level  of  oversight  that  limits  productivity. 

As  laser  technology  develops,  it  will  be  necessary  to  ensure  that  the  policies 
develop  as  well.  However,  as  with  any  newer  technology,  the  knowledge  base,  policies  in 
place  and  SME  availability  will  need  time  to  grow.  This  affects  the  manner  in  which  DS 
can  be  applied.  Lack  of  past  experience  and  knowledge  adds  to  the  increased  risk  in 
designing  for  DS  as  there  is  less  historical  data  to  leverage.  The  components  of  the  laser 
are  directly  related  to  the  sensorization  of  LREis,  which  were  identified  by  the  DHSEL 
team.  The  LREis  of  the  laser  need  to  be  monitored  in  order  to  prepare  and  mitigate 
problems  arising  from  use  and  environmental  factors  (Paschotta  2014). 

The  United  States  Government  Accountability  Office  (GAO)  released  a  status 
report  in  2005  regarding  the  DOD  implementation  of  the  HEL  Master  plan  (Department 
of  Defense  2000).  Overall,  S&T  had  grown  proportionally  to  the  planned  investments. 
Considerable  advancements  in  technology  were  being  achieved  and  the  forces  had 
increased  applied  research  to  the  fielding  of  HEL  weapon  systems  and  overall  the  plan 
was  being  executed  as  designed.  The  Department  of  the  Navy  (DON)  specifically  had 
developed  requirements  to  incorporate  technologies  based  on  electric  ships,  submarines, 
and  aircraft  in  the  areas  of  EEL  and  SSL  for  the  maritime  environment. 


42 


By  2014  the  Office  of  Naval  Research  (ONR)  had  begun  the  stages  of  test  bed 
demonstration  in  the  Pre -Milestone  A  phase  of  the  acquisition  life  cycle  known  as  the 
quick  reaction  capability  (QRC).  While  not  currently  at  the  stage  of  transitioning  from 
S&T  to  a  program  of  record,  the  technology  advancement  has  so  far  proven  successful 
and  reached  the  point  where  lasers  capable  of  countering  certain  surface  and  air  targets  at 
ranges  of  about  a  mile  could  be  made  ready  for  installation  on  USN  surface  ships  over  the 
next  few  years.  The  USN  reportedly  anticipates  moving  to  a  shipboard  laser  program  of 
record  in  “the  FY2018  time  frame”  and  achieving  an  initial  operational  capability  (IOC) 
with  a  shipboard  laser  in  FY2020  or  FY2021  (O’Rourke  2014). 

However,  there  exists  a  recommendation  from  the  original  laser  HEL  Master  Plan 
which  still  holds  true. 

The  Department  will  not  be  able  to  field  HEL  weapons  if  the  supplier  base 
continues  to  decline  or  if  universities  do  not  produce  enough  graduates 
with  the  skills  or  motivation  to  work  in  this  area.  A  few  well-directed 
program  initiatives  could  stimulate  development  of  promising  new 
technologies  and  at  the  same  time  create  a  demand  for  essential  skills. 
(Department  of  Defense  2000) 

The  resource  base  of  SMEs  is  limited  to  the  point  where  there  was  risk  in  the 
ability  to  even  field  a  HEL  system.  While  the  SME  base  has  grown  to  the  point  where 
fielding  a  system  became  possible,  this  recommendation  was  focused  solely  on  fielding  a 
system.  To  successfully  sustain  the  system  throughout  the  life  cycle,  DOD  is  faced  with 
the  challenge  of  connecting  the  limited  group  of  HEL  SMEs  to  a  massive  number  of 
fielded  laser  weapon  systems  installed  on  ships  throughout  the  Elect.  A  support  capability 
to  enable  communication  of  the  “few  to  many”  must  be  evaluated.  DSHEL  is  the 
proposed  capability  to  fill  this  gap. 

2.  Implicit  Areas 

The  implicit  areas  (indirectly  related)  that  were  researched  and  reviewed  for 
DSHEL  analyzed  the  impact  and  importance  of  government  and  military  policies,  open 
architecture  requirements,  cybersecurity  requirements,  Internet  of  Things  (loT) 
characteristics,  platform,  and  infrastructure  considerations. 


43 


a.  Cybersecurity 

The  purpose  of  this  seetion  is  to  identify  DOD  mandated  requirements  for 
eyberseeurity,  speeial  eonsiderations  regarding  implementation  and  management,  as  well 
as  the  effeets  it  has  on  the  systems  engineering  proeess  in  the  life  eyele  of  DSHEL. 
Distanee  support  enables  interfaees  to  the  GIG,  whieh  must  be  properly  designed  and 
managed  for  a  sueeessful  seeure  implementation. 

(1)  Programmatie  Guidanee 

Traditionally  in  DOD,  this  respeetive  subjeet  matter  has  been  known  widely  as 
information  assuranee  (lA),  formally  defined  as  information  operations  that  proteet  and 
defend  information  and  information  systems  by  ensuring  their  availability,  integrity, 
authentieation,  eonfidentiality,  and  non-repudiation  (Department  of  Defense  Chief 
Information  Offieer  2006).  This  ineludes  providing  for  the  restoration  of  information 
systems  by  ineorporating  proteetion,  deteetion,  and  reaetion  eapabilities.  It  has  a  general 
broadening  foeus  whieh  ineludes  the  proteetion  of  digital  and  non-digital  information 
assets,  sueh  as  paper  reeords.  While  these  methodologies  at  a  high  level  are  still 
applieable  today,  mueh  information  has  been  digitized  and  exists  solely  in  an  information 
system  environment.  As  sueh,  the  proeesses,  rules,  and  regulations,  whieh  treated  data  on 
a  eomputer  in  the  same  sense  as  a  physieal  reeord,  did  not  translate  well,  resulting  in  a 
vague,  diffieult,  and  ineffieient  proeess  to  properly  manage  modem  systems  in  the  DOD. 
Due  to  this,  information  systems  seeurity  (eyberseeurity)  is  now  the  foeus.  Seen  as  a 
subset  of  information  assuranee,  eyberseeurity  foeuses  more  on  the  teehnieal  prevention 
and  defense  of  information  systems,  whieh  ineludes  eomputers,  networks,  programs,  and 
data.  Risk  management  is  a  eore  eompeteney  of  this  paradigm  and  was  deeomposed 
further  in  the  risk  management  seetion  of  this  eapstone  report.  As  of  FY2014,  the  DOD 
has  issued  new  mandates  on  guidanee  in  the  risk  management  framework  (RMF) 
regarding  the  implementation  of  eyberseeurity  in  all  system  aequisition  spanning  from 
the  milestone  deeision  authority,  researeh,  developmental,  test  and  evaluation,  and 
sustainment  efforts.  The  information  presented  here  forth  is  eommon  to  all  systems,  the 
POI  (HFF),  and  the  proposed  distanee  support  eomponent  implementation  of  DSHFF. 
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A  core  difference  in  the  newest  guidance  is  the  concept  of  cybersecurity 
reciprocity.  The  implementation  of  best  practices  and  type  accreditation  can  benefit  all 
and  have  a  greater,  more  positive  outcome  for  the  DOD.  Applied  appropriately, 
reciprocity  reduces  redundant  testing,  assessing  and  documentation,  and  the  associated 
costs  in  time  and  resources.  In  order  to  facilitate  reciprocity,  the  following  concepts  and 
practices  are  assumed  to  occur  during  systems  development:  acceptance  of  existing  cyber 
test  and  assessment  results  and  authorization  documentation.  IS  and  PIT  systems  have 
only  a  single  valid  authorization.  Multiple  authorizations  indicate  multiple  systems  under 
separate  ownership  and  configuration  control.  Deploying  systems  with  valid 
authorizations  are  to  be  accepted  into  receiving  organizations  without  adversely  affecting 
the  authorizations  of  either  the  deployed  system  or  the  receiving  enclave  or  site.  An 
authorization  decision  for  a  system  cannot  be  made  without  completing  the  required 
assessments  and  analysis,  as  recorded  in  the  security  authorization  package.  Deploying 
organizations  must  provide  the  complete  security  authorization  package  to  receiving 
organizations.  Overarching  organizations  and  higher-level  systems,  such  as  shipboard 
network  infrastructures,  should  provide  core  defenses  to  strengthen  cybersecurity  and 
those  controls  be  inherited  by  the  smaller  sub-systems.  Reciprocity  insists  that  developers 
will  design  and  accredit  their  systems  with  the  foresight  of  maximal  re-use  by  other 
organizations,  and  in  return,  developers  can  interoperate  and  reuse  other  existing  systems. 
This  saves  the  DOD  resources  in  redundant  paperwork  and  delayed  accreditation  time 
frames  for  systems,  which  are  already  authorized  for  use  elsewhere. 

With  these  core  concepts,  the  programmatic  cybersecurity  requirements  for  a 
given  system  help  to  define  the  acquisition  roadmap,  tailoring  of  systems  engineering 
methodologies,  and  sustainment  of  a  system  throughout  the  life  cycle.  However,  a  core 
concept  of  systems  realization  with  cybersecurity  includes  the  training  and  certification 
of  people  throughout  the  acquisition  life  cycle.  Prior  to  development  taking  place,  the 
developer  must  have  the  appropriate  personnel  to  perform  certain  tasking.  Qualified 
cybersecurity  personnel  must  be  identified  and  integrated  into  all  phases  of  the  system 
development  life  cycle.  The  necessary  training  for  the  given  roles  and  responsibilities, 
ensures  that  acquisition  community  personnel  with  IT  development  responsibilities  are 
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qualified  in  accordance  with  DOD  8570. 10-M.  To  design,  plan,  implement,  and  manage 
the  cybersecurity  of  systems,  special  cybersecurity  workforce  (CSWF)  certifications  are 
required. 

Along  with  these  updated  requirements  is  a  modification  to  the  acquisition 
roadmap,  sometimes  known  as  the  defense  acquisition  “Horse  Blanket.”  Previous 
information  assurance  methodologies  only  required  authority  to  operate  (ATO) 
certification  by  the  IOC  of  a  systems  maturity  near  Milestone  C,  with  appropriate  interim 
authorities  to  test  (lATT)  during  development.  Now,  cybersecurity  mandates  specific 
entrance  criteria  to  milestone  decisions  and  development  phases  as  can  be  seen  in  the 
modified  acquisition  roadmap  of  Figure  18.  These  steps  are  required  for  HEL  regardless 
of  how  the  DHSEL  subsystem  is  implemented. 
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Alignment  of  RMF  and  DoD  Acquisition  System  Activities 
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RMF  Step  4  -  Assess  security  controls  (issue  lATTs  as  needed) 
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RMF  Step  5  -  Authorize  system  (issue  ATO) 
Operational  Test  &  Evaluation  (OT&E) 

RMF  Step  6  -  Monitor  security  controls 


Figure  18.  Alignment  of  RMF  and  DOD  Aequisition  System  Activities  (from  Department  of  Defense  2014) 
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The  above  proeess  of  RMF  steps  aligns  with  the  risk  management  proeess  for 
eyberseeurity.  Regarding  speeifie  milestones  to  defense  aequisition,  the  follow 
requirements  are  now  mandatory  for  all  systems  throughout  the  life  eyele.  During  the 
Materiel  Solution  Analysis,  Pre  Milestone  A,  the  program’s  information  assuranee 
manager  (lAM)  shall  develop  an  lA  strategy.  This  plan  doeuments  the  roadmap  for 
aeereditation  through  development  and  sustainment  of  a  system,  alongside  the  proposed 
eategorization  (PIT  &  IS),  as  well  as  the  conceptual  processes,  architecture,  and 
organizations  for  meeting  eyberseeurity  requirements.  This  strategy  is  required  to  be 
updated  subsequently  at  every  milestone  decision  as  the  system  enters  the  next  stage  of 
development. 

At  step  two,  the  security  controls  from  the  NIST  800-53  “Recommended  Security 
Controls  for  Federal  Information  Systems  and  Organizations”  are  selected  and  made  part 
of  the  system  baseline.  They  are  added  to  the  Joint  Capabilities  Integration  and 
Development  System  (JCIDS),  which  is  what  DOD  uses  to  designate  acquisition 
requirements  and  evaluation  criteria  for  defense  programs.  This  translates  to  a  developer 
that  eyberseeurity  requirements  are  equally  as  important  as  functional  requirements,  e.g., 
the  security  posture  of  a  laser  system  matters  as  much  as  its  beam  propagation,  in  terms 
of  defense  acquisition. 

Program  initiation  at  Milestone  B  requires  the  Preliminary  Design  Review  (PDR) 

to  cover  and  receive  programmatic  approval  for  the  security  design  and  planning  thus  far. 

If  it  is  sufficient  and  the  program  proceeds  to  Engineering  and  Manufacturing 

Development  (EMD),  the  appropriate  security  engineers  then  take  the  higher  level 

controls  and  translate  them  into  technical  design.  Typically,  Defense  Information  System 

Agency  (DISA)  provided  Security  Technical  Implementation  Guides  (STIGs)  are  used  to 

“lock  down”  the  system  to  the  point  where  required  functionality  and  other  system  key 

performance  parameters  are  not  affected.  This  ensures  that  security  is  designed  in  up 

front  and  can  co-exist  with  functional  parameters.  This  is  also  a  critical  stage  in 

development,  as  the  technology  matures,  the  test  and  evaluation  (T&E)  teams  are 

preparing  the  test  and  evaluation  master  plan  (TEMP)  aligned  with  step  four  of  RMF. 

New  eyberseeurity  requirements  now  mandate  that  security  controls  go  through  equal 
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amounts  of  test  and  evaluation  and  are  deseribed  at  high  level  in  the  RMF  instruetion  and 
in  great  detail  throughout  DODM-7994  “Proeedures  for  Operational  Test  and  Evaluation 
of  Cyberseeurity  in  Aequisition  Programs.”  The  high  level  RMF  deseribes  penetration 
testing,  where  certified  independent  teams  of  ethical  hackers  are  brought  in  to  test  the 
security  posture  of  the  system.  These  test  results  are  reviewed  and  at  a  minimum  meet  the 
measures  of  effectiveness  thresholds  described  in  DODM-7994.  Evaluation  of 
cyberseeurity  during  an  acquisition  T&E  event  must  include  independent  threat 
representative  penetration,  exploitation  testing,  and  evaluation  of  the  complete  system 
cyberspace  defenses.  This  also  includes  the  controls  and  protections  provided  by 
computer  network  defense  service  providers.  Penetration  and  exploitation  testing  must  be 
planned  and  resourced  as  part  of  the  DT&E  and  OT&E  via  the  appropriate  program  test 
documentation. 

An  lATT  is  a  required  certification  for  any  developmental  test  event  and  must  be 
acquired  prior  to  the  beginning  of  DT  for  execution  of  the  TEMP  during  step  four. 
Developmental  testing  is  exceptionally  important  for  cyberseeurity,  as  it  will  identify 
controls  and  technical  implementations  which  may  impact  system  functional 
performance.  These  findings  are  refined  if  possible,  and  are  managed  risks  between  the 
program  and  designation  officials.  The  end  goal  being  to  predict  the  operational  baseline 
and  obtain  ATO  by  Milestone  C  for  initial  operational  test  and  evaluation  (lOT&E)  at 
RME  step  five. 

Once  the  system  is  operational  at  step  six,  continuous  monitoring  and  cyber  risk 
management  occurs  throughout  the  life  cycle  until  system  deactivation  and  disposal.  This 
requires  periodic  system  configuration  scanning  on  a  monthly  basis  and  re-accreditation 
every  four  years.  Eiscal  requirements  of  the  program  office  thus  require  programmatic 
objective  memorandum  (POM)  funding  to  allocate  funding  to  sustain  the  system, 
including  resourcing  for  certified  CSWE  personnel  to  provide  system  patches  and 
upgrades  keeping  the  system  secure  throughout  the  life  cycle.  Even  if  a  system  still  meets 
functional  requirements  and  has  no  high  priority  user  reported  items  from  the  Elect,  it  is 
mandated  by  the  accreditation  authority  that  the  core  operating  system  software  of  any 
system  receive  security  patches  on  a  periodic  basis.  The  periodicity  depends  on  the 
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tactical  vs  non-tactical  use  of  a  system  as  well  as  how  high  of  a  priority  existing  seeurity 
threats  present. 

Above  all,  when  eonsidering  the  eertifieation  proeess,  it  is  important  to  foeus  on 
how  the  system  aeereditation  boundaries  are  drawn  for  DSHEL  to  ensure  the  system  is 
sustainable.  While  the  DSHEL  is  proposed  as  a  DS  subsystem  of  HEL,  making  it 
physieally  part  of  the  system,  the  systems  lA  boundaries  must  be  deeomposed  into  the 
parts,  which  are  functionally  partitioned.  A  weapon  is  typieally  aeeredited  as  a  PIT 
System,  where  more  risk  is  aeeepted  to  freeze  the  software  baseline  up  to  four  years.  This 
means  information  assuranee  vulnerability  alert  (lAVA)  patches  are  typieally  not 
installed  unless  a  high  priority  issue  affeeting  safety  is  discovered.  To  aecount  for  the  faet 
that  weapons  have  an  entirely  separate  eertifieation  proeess  through  the  Weapon  System 
Explosive  Safety  Review  Board  (WSERB),  extensive  integration  and  shipboard  test 
events  are  required  to  eertify  and  look  down  a  weapon  system  baseline  by  the  Naval 
Systems  Engineering  Direotorate  (NAVSEA  05),  and  rolls  up  into  a  larger  oombat  system 
eertifieation.  If  a  weapon  were  patched  on  a  monthly  basis,  the  oost  would  be 
unsustainable  for  the  neoessary  rigor  to  ensure  the  system  is  still  safe,  which  is  why  this 
risk  is  typically  accepted.  By  partitioning  DSHEL  from  HEL  within  the  oyber  security 
accreditation  boundary,  the  HEL  weapon  system  oan  maintain  its  PIT  System 
aooreditation  whereas  the  DSHEL  would  designate  as  an  IS,  aeeredited  by  ATO.  The 
system  is  broken  into  what  the  functional  laser  weapon  would  be  by  design  and  its 
distanoe  support  oounterpart,  permitted  to  interfaee  by  a  PIT  and  an  IS  intereonneet 
agreement.  This  in  turn  allows  HEL  to  have  a  frozen  baseline  where  the  DSHEL,  whieh 
is  the  only  part  eommunieating  with  the  GIG,  ean  reeeive  periodic  lAVA  patches  to 
ensure  the  risk  ean  be  managed  appropriately  without  invalidating  the  NAVSEA05 
eertifieation  of  the  laser.  Pending  the  future  design  of  the  PoR  HEL,  it  may  even  be 
possible  to  fully  aeeredit  the  HEL  system  as  PIT,  with  DHSEL  defined  as  a  PIT 
Intereonneet  (PITI)  if  the  transfer  of  data  is  fully  enough  defined.  This  eonsideration  must 
be  fully  evaluated  at  the  time  of  realization  with  the  designated  approving  authority 
(DAA).  Design  eonsiderations  are  addressed  in  the  Teehnieal  Implementation  seetion. 
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(2)  Technical  Implementation 

The  high-level  requirements,  technical  considerations,  and  security  controls  of 
RMF  must  be  rigorously  addressed.  While  full  technical  design  cannot  facilitate  without 
proper  system  functional  requirements,  the  following  best  practices  are  used  to  minimize 
effort  and  maximize  reuse  of  existing  applications. 

By  partitioning  the  HEL  and  DSHEL  accreditation  boundaries,  a  balance  can  be 
achieved  which  does  not  impose  changes  to  an  already  rigorously  tested  and  certified 
HEE  weapon  system  while  still  providing  a  secure  connection  to  enable  distance  support. 
An  interconnect  agreement  between  the  DSHEE  (Information  System)  and  the  HEE 
(Platform  IT)  still  requires  that  the  interface  be  managed  and  secured.  This  is  best 
achieved  at  a  minimum  through  the  use  of  a  firewall  and  an  approved  set  of  ports, 
protocols,  and  services,  which  are  permitted  between  DSHEL  and  HEL.  The 
aforementioned  is  typically  referred  to  as  a  “white  list,”  where  certain  data  is  identified  as 
permitted  and  all  other  formats,  ports,  and  connections  are  denied.  This  implementation 
must  be  applied  to  all  external  interfaces  of  DSHEL,  going  to  HEL  as  well  as  to  the 
shipboard  network.  In  turn,  this  creates  a  security  wrapper  around  the  information  system 
where  only  approved  ports,  protocols,  and  services  will  be  allowed.  DSHEL  would  then 
not  only  be  secure  by  technical  design,  but  can  also  receive  periodic  lAVA  patches  to  its 
operating  system  (OS)  to  minimize  risk  and  maintain  ATO  certification. 

The  core  underlying  effort  of  most  cybersecurity  is  applied  to  the  OS  of  the 

computer  asset.  An  OS  is  software  that  manages  the  computer  hardware  and  software 

resources  and  provides  common  services  for  computer  programs.  It  is  an  essential 

component  of  any  system  and  OS’s  exists  on  network  switches,  to  personal  computers,  to 

servers.  DISA  provided  STIG’s  guide  a  security  engineer  on  how  to  configure  a  systems 

OS  in  order  to  meet  necessary  security  controls  and  exist  for  almost  every  major  COTS 

software  systems:  e.g.,  Microsoft  Windows,  Red  Hat  Enterprise  Linux  (RHEL),  CISCO 

lOS.  The  application  of  STIGs  takes  considerable  effort  in  person  hours  to  accomplish, 

which  is  why  DISA  provides  baseline  images  for  free  as  a  download  from  their  site, 

incorporating  a  majority  of  these  security  controls  which  do  not  impact  performance, 

leaving  the  remaining  work  to  be  complete  by  the  program’s  security  engineer.  While  the 
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DISA  image  is  provided  for  free,  it  is  still  the  obligation  of  the  Program  Sponsor  to  pay 
any  required  lieensing  fees  of  the  COTS  OS  manufaeturer,  a  sunk  eost  eonsidering  it 
must  be  lieensed  either  way.  Given  the  amount  of  time  it  takes  to  “look  down”  a  system 
as  well  as  to  maintain  the  seourity  of  a  system,  up  front  oonsideration  must  be  made  on 
COTS  selection  given  the  required  functionality.  It  must  be  noted  that  DISA  images  are 
basically  locked  down  to  a  point  where  they  are  almost  not  functional,  which  allows  the 
security  engineering  to  open  required  services  up  and  provide  any  addition  STIG 
configurations  necessary.  The  entire  process  is  managing  risk,  in  that  how  much  tradeoff 
between  cybersecurity  and  functional  capability  can  be  accepted  as  reasonable  risk. 
Leveraging  the  secured  images  is  a  key  asset  in  development,  where  some  programs  may 
make  the  pitfall  of  using  other  OS’s  not  supported  by  DISA,  such  as  CentOS  or  Ubuntu, 
thus,  applying  the  STIG  from  a  fresh  install  of  Windows  or  RHEL.  This  results  in  a 
duplication  of  effort  which  has  already  been  completed  by  another  government 
organization. 

Alongside  the  core  OS  is  the  defense-in-depth  architecture  granting  least  privilege 
to  a  user.  Legacy  systems  base  their  design  around  being  completely  open.  This  induces 
security  risks  and  maintenance  costs  to  sustain  system  accreditation.  Locking  down  the 
system  to  only  the  required  ports,  protocols,  and  services  mitigates  much  of  this  risk.  In 
addition,  defensive  cyber  security  products  (e.g.,  firewalls,  file  integrity  checkers,  virus 
scanners,  intrusion  detection  systems,  anti-malware  software)  should  be  included  if 
possible  and  operate  in  a  GIG  connected  manner  to  enhance  the  exchange  of  data  and 
shared  security  policies.  Overall,  fundamental  system  requirements  for  functionality  are 
required  to  delve  further  into  technical  application  and  were  developed  by  the  DSHEL 
team  in  the  following  requirements  section;  the  takeaway  is  that  many  options  exist  for  a 
program  to  implement  secure  systems,  and  they  must  be  investigated  early  in  systems 
development. 

The  aforementioned  division  of  HEL  from  DSHEL  accommodates  the  current  “as 
is”  network  infrastructure  that  exists  in  the  Elect.  While  current  RME  concepts  of 
reciprocity  would  dictate  otherwise  to  minimize  rework  of  cyber  controls,  this  in  turn 
requires  each  system  to  bring  aboard  their  cyber  solution  and  accredit  as  such.  Euture 
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shipboard  network  architectures  leverage  infrastructure  level  firewalls,  host  based 
security  systems,  antivirus,  and  other  shared  cyber  resources,  which  could  be  leveraged 
by  the  HEL.  While  it  would  not  fully  satisfy  all  cyber  requirements  imposed  on  HEL, 
many  of  the  controls  would  reciprocate  and  be  inherited  to  secure  the  DHSEE  sub¬ 
system.  As  a  baseline  effort,  these  requirements  were  identified  in  this  report  and  for 
legacy  host  platforms  must  be  designed-in  to  HEE.  Euture  architectures  in  the 
developmental  stages  of  the  life  cycle  would  then  require  the  HEE  developer  to  perform  a 
requirements  analysis  to  determine  which  controls  were  already  satisfied  by  the 
shipboard  infrastructure.  If  the  boundary  defense  is  sufficient  in  implementation,  the 
DSHEE  can  avoid  being  partitioned  out  as  an  IS,  thus  remaining  part  of  the  HEE  weapon 
system  accreditation,  and  achieve  functional  transfer  of  data  off  ship  by  leveraging  the 
infrastructure  as  a  service  (laaS)  DS  gateway.  Potential  future  implementations  of 
shipboard  infrastructure  are  beyond  the  scope  of  this  report  to  go  into  sufficient  detail; 
however,  they  were  identified  as  an  area  of  future  research  in  the  summary  section. 

By  following  the  recommended  procedures,  artifact  creation,  and  technical 
implementation  through  the  systems  engineering  process,  DSHEE  can  be  realized  into  a 
secure  functional  capability  of  HEE. 

b.  Open  Systems  Architecture 

To  leverage  the  abundance  of  free  open  source  software  (EOSS)  and  COTS 
applications,  which  exist  to  enable  DS  of  HEE,  open  standards  and  protocols  must  be 
leveraged.  The  DOD  preferred  approach  for  implementation  of  open  systems,  previously 
called  modular  open  systems  approach  (MOSA),  is  now  called  open  systems  architecture 
(OSA).  Per  the  Office  of  the  Deputy  Assistant  Secretary  of  Defense, 

Technology  evolution  and  lessons  learned  have  led  to  DOD  guidance 
suggesting  the  move  away  from  MIE-STD  proprietary  interfaces,  both 
physical  and  logical,  to  the  use  of  industry  standard  open  interfaces  such 
that  system  modules  are  decoupled.  The  use  of  industry  OSA  is  both  a 
business  and  technical  strategy  for  developing  a  new  system  or 
modernizing  an  existing  one.  OSA  enables  acquisition  and  engineering 
communities  to  design  for  affordable  change,  employ  evolutionary 
acquisition  development,  spiral  development,  and  develop  an  integrated 


53 


roadmap  for  system  design  and  development.  Basing  design  strategies  on 
widely  supported  open  standards  increases  the  chance  that  future  changes 
to  the  system  will  be  integrated  in  a  cost-effective  manner.  Open  systems 
employ  modular  design,  use  widely  supported  and  consensus-based 
standards  for  their  key  interfaces,  and  have  been  subjected  to  successful 
validation  and  verification  tests  to  ensure  the  openness  of  their  key 
interfaces.  (United  States  Department  of  Defense  2015) 

The  open  systems  architecture  contract  guidebook  was  released  in  May  2013, 
providing  passive  DOD  stakeholder  requirements,  checklists,  and  contractual 
specifications  to  enable  the  fundamental  principles  of  OSA  as  stated  in  the  guidebook 
(United  States  Department  of  Defense,  2013): 

1.  Modular  designs  based  on  standards,  with  loose  coupling  and  high 
cohesion,  that  allow  for  independent  acquisition  of  system  components 

2.  Enterprise  investment  strategies,  based  on  collaboration  and  trust,  that 
maximize  reuse  of  proven  hardware  system  designs  and  ensure  we  spend 
the  least  to  get  the  best 

3.  Transformation  of  the  life-cycle  sustainment  strategies  for  software 
intensive  systems  through  proven  technology  insertion  and  software 
product  upgrade  techniques 

4.  Dramatically  lower  development  risk  through  transparency  of  system 
designs,  continuous  design  disclosure,  and  government,  academia,  and 
industry  peer  reviews 

5.  Strategic  use  of  data  rights  to  ensure  a  level  competitive  playing  field 
and  access  to  alternative  solutions  and  sources,  across  the  life  cycle 

A  mandate  of  OSA  is  that  technical  requirements  be  based  to  the  maximum  extent 
practicable  on  open  standards.  Where  there  are  no  standards,  the  OSA  methodology 
creates  them.  At  a  minimum,  technical  standards  and  related  specifications,  requirements, 
source  code,  metadata,  interface  control  documents  (ICDs),  and  any  other 
implementation  and  design  artifacts  that  are  necessary  for  a  qualified  contractor  to 
successfully  perform  development  or  maintenance  work  for  the  government  are  made 
available  throughout  the  life  cycle  (United  States  Department  of  Defense  2013). 

Due  to  this  mandate,  there  are  a  number  of  boilerplate  requirements,  which  were 
to  be  leveraged  for  the  implementation  of  DSHEL.  This  begins  with  the  need  for  the 
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developer  to  submit  to  the  government  an  open  system  management  plan  as  set  forth  in 
the  eontraet  data  requirements  list  (CDRL).  This  begins  with  the  teehnical  approach  and 
decomposes  in  to  design  disclosure  for  technical  data  rights  such  that  the  customer  can 
accept,  maintain,  and  sustain  the  system  with  COTS  refresh  items  as  acceptable 
replacements  due  to  the  use  of  OSA  standards.  This  enforces  the  justification  of  vendor 
specific  proprietary  interfaces  when  open  ones  cannot  be  leveraged. 

Early  and  often  technical  disclosure  is  a  recent  mandate.  Submitting  plans,  which 
describe  the  information  disclosure  methodology,  computer  resources  necessary,  are 
required  to  enable  collaboration  and  a  common  knowledge  base  for  all  those  involved. 
This  technical  data  also  can  not  have  any  restrictive  markings  prohibiting  the  re-use  of 
source  material  for  the  customer.  Moreover,  the  use  of  FOSS  is  encouraged  as  technical 
data  to  permit  reuse  of  open  standard  interfaces  among  COTS  software.  The  OSA  guide 
not  only  mandates  the  use  of  OSA,  but  also  a  sense  of  fiscal  responsibility,  which  will  not 
inhibit  the  DOD  from  life-cycle  management  of  the  system. 

c.  Infrastructure 

In  order  to  properly  execute  DS  for  the  HEL,  it  is  necessary  to  maintain  a  reliable 
ship  to  shore  connection.  To  accomplish  this,  it  was  necessary  for  this  research  to  capture 
the  requirements  and  capabilities  necessary  for  effective  ship  to  shore  communication. 
Although  data  integrity  and  security  of  the  GIG  is  of  the  utmost  importance,  this  section 
will  focus  on  the  performance  requirements  of  the  transport  layer. 

Any  connection  made  from  the  shore  to  the  ship  happens  through  one  of  several 
NOC  around  the  world.  In  order  for  a  USN  shore  facility  to  gain  access  to  the  ship 
through  the  NOC,  a  firewall  service  request  (FSR)  must  be  submitted  to  the  NOC 
indicating  the  require  subnet  address  space  as  well  as  the  ports  protocols  and  services 
(EPS)  that  will  be  transmitted  through  the  NOC  firewall.  Once  this  has  been  completed, 
the  NOC  firewall  will  be  modified  to  allow  connection  to  the  designated  ship. 

In  the  case  of  the  guided  missile  destroyer  (DDG)  platform,  the  inbound 
connection  for  TCP/IP  happens  through  the  shipboard  super  high  frequency  (SHF).  Once 
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the  radio  frequency  (RF)  signal  is  received  by  the  SHF  antenna,  the  signal  will  be 
decrypted  and  then  passed  to  the  Main  Shipboard  Routing  System  for  the  ship  known  as 
the  Automated  Digital  Network  System  (ADNS).  From  ADNS,  the  information  will  pass 
to  the  Integrated  Shipboard  Network  System  (ISNS),  which  acts  as  the  main  transport 
layer  for  the  ship.  Since  the  HEL  System  is  being  developed  as  a  ship  self-defense 
weapon  system,  the  data  needs  to  move  from  the  ISNS  domain  of  the  ship  into  the 
combat  systems  domain  of  the  ship.  The  combat  systems  network  on  the  DDG  platform 
is  the  Aegis  LAN  Interconnect  System  (ALIS).  Typically,  ALIS  does  not  maintain  a 
persistent  connection  to  ISNS.  For  the  DSHEL  system,  a  persistent  connection  between 
ALIS  and  ISNS  would  be  required.  To  help  provide  a  layer  of  security  between  these  two 
ship  domains,  the  DSHEL  system  shall  employ  a  boundary  firewall  to  maintain  the 
security  of  the  information  and  ensure  protection  of  each  domain.  Once  inside  the  ALIS 
network,  the  information  would  get  to  the  DSHEL  system  and  then  to  the  HEL  system 
itself. 

In  the  case  of  the  LCS  platform,  the  path  to  the  ship  is  completely  the  same  until 
the  signal  hits  the  ADNS  routers.  Once  the  signal  passes  the  ADNS  routers,  it  enters  the 
Total  Ship  Computing  Environment  (TSCE).  This  environment  acts  as  the  transport  layer 
for  the  ship,  combining  the  previous  ISNS  and  ALIS  networks  into  a  single  backbone. 
Lrom  the  TSCE,  the  signal  will  travel  through  the  TSCE  firewall  into  the  combat  virtual 
local  area  network  (VLAN)  and  then  to  the  DSHEL  system.  Eigure  19  shows  this 
connection  path. 

In  each  of  the  cases,  the  total  data  throughput  off  the  ship  through  the  ADNS 
routers  is  allocated  to  be  2Mbps.  Additionally,  the  SHE  is  not  Line  of  Sight  (LoS);  rather 
it  is  via  satellite  communications  (SATCOM)  over  the  horizon,  which  can  add  an 
additional  800  ms  round  trip  delay  ship  to  shore.  This  delay  causes  significant  overhead 
due  to  the  fact  that  many  TCP/IP  packets  could  potentially  exceed  the  minimum  transmit 
unit  (MTU)  time  provided.  These  can  be  dropped  in  the  transmission  process.  Given  the 
constrained  bandwidth  environment,  it  was  necessary  to  have  a  requirement  for  the 
DSHEL  system  that  all  data  transmitted  off  ship  would  have  to  be  analyzed  for  criticality 
discarding  non-essential  data  and  then  compressed  prior  to  transmitting  off  ship. 
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d.  Big  Data  and  Data  Science 


Big  data  is  a  term  that  defines  extremely  large,  complex  data  sets  that  are 
challenging  to  collect,  verify,  validate,  process,  analyze,  store,  search,  transport,  share, 
and  secure.  Data  science  is  the  analysis  of,  and  extraction  of  knowledge  from  big  data. 
These  terms  are  very  general  due  to  there  being  no  standard  definition.  This  paper  will 
use  the  ONR  and  RAND  definition  of  big  data  by  the  analysis  of  its  characteristics.  Big 
data  is  defined  by  four  characteristics  (Porsche,  Wilson,  Johnson,  Tierney,  and  Saltzman 
2014); 

•  volume  of  data 

•  variety  of  formats,  sources,  and  types 

•  velocity  of  searches  and  data  retrieval 

•  veracity  of  conclusions  based  on  data 

The  reason  big  data  is  defined  by  the  characteristics  and  properties  above  is  due  to 
it  being  a  moving  target.  The  amount  of  data  and  the  speed  at  which  it  is  processed  is 
relative  to  the  progression  of  technology.  Even  with  these  relative  benchmarks,  one  fact 
remains  certain:  the  USN  arguably  faces  one  of  the  most  complex  big  data  challenges  in 
the  Information  Age. 

With  the  growth  of  the  Internet  of  Things  (loT),  interconnected  and  networked 
devices  have  found  their  way  into  all  aspects  of  life.  From  coffee  makers  to  aircraft 
engines,  sensorization  of  these  devices  has  captured  information  that  can  be  used  to 
increase  product  maintainability,  availability,  and  increase  capability.  In  acquiring  COTS 
products,  the  USN  now  has  access  to  these  data  recording  and  reporting  tools  that  are 
built  into  these  systems.  While  these  tools  bring  the  promise  of  the  benefits  of  the  product 
increases  listed  above,  they  will  also  bring  about  some  major  challenges. 

A  typical  Boeing  737  engine  generates  10  terabytes  of  data  every  30  minutes  in 
flight  (Mathai  2011).  While  this  amount  of  data  may  seem  substantial,  all  of  the 
information  housed  in  the  Library  of  Congress  totals  to  only  be  200  terabytes  (Porsche, 
Wilson,  Johnson,  Tierney,  and  Saltzman  2014).  A  USN  Arleigh  Burke  Class  Guided 
Missile  Destroyer  has  four  gas  turbine  engines.  With  a  typical  deployment  lasting  six 
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months,  this  means  the  data  generated  by  the  gas  turbine  engines  alone  would  total  to  be 
87,658  terabytes  or  87  petabytes.  If  this  amount  of  data  was  to  be  burned  to  eompact 
discs  (CDs),  125  million  CDs  would  be  needed.  Stacking  each  of  these  CDs  on  top  of  one 
another  would  result  in  a  tower  of  CDs  reaching  93  miles  into  the  sky.  This  is  438  times 
more  data  than  that  of  the  entirety  of  the  Library  of  Congress.  In  fact,  a  single  destroyer 
on  deployment  would  generate  the  equivalent  of  a  Library  of  Congress’  worth  of  data  in 
about  ten  hours.  This  amount  of  data  only  accounts  for  the  gas  turbine  engines  alone  and 
does  not  include  the  rest  of  the  systems  on  board  of  the  ship  (such  as  radar, 
communication,  weapons,  mechanical,  network).  When  the  complete  data  picture  of  USN 
is  put  together  (logistics,  support  structures,  administrative  services,  surface,  subsurface, 
air,  land,  and  space),  the  sheer  amount  of  data  becomes  mind-boggling,  as  shown  in 
Figure  19. 
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Figure  19.  Exponential  Increase  of  Data  Generated  as  USN  Acquires  New  Sensors 

(from  Porche  et  al.  2011,  5) 


It  was  important  for  DSHEL  to  understand  the  big  data  challenge  because  as  the 
current  trends  show,  the  amount  of  data  is  only  increasing  and  the  main  information 


needed  to  provide  support  to  a  system  is  data. 
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3,  Summary 

Throughout  DSHEL’s  literature  review,  it  beeame  apparent  that  a  knowledge  gap 
existed  in  multiple  areas  ereating  a  need  for  a  system  that  DSHEL  would  fill.  The  current 
state  of  DS  is  fractured.  There  lies  a  functional  and  communication  gap  in  between  the 
systems  and  the  service  provider  organizations.  In  order  to  provide  adequate  DS  to  the 
HEE,  an  integrated  DS  framework  must  first  be  created.  This  solution  must  be  flexible, 
modular,  efficient,  maintainable,  as  well  as  adhere  to  all  the  unique  policies  and 
regulations  of  the  EISN. 

B,  DISTANCE  SUPPORT  FRAMEWORK 

At  its  highest  level,  DS  is  a  concept  that  is  delivered  as  a  service  to  a  platform 
through  hardware,  software,  or  a  combination  of  both.  To  execute  DS,  three  basic 
elements  are  required;  platform  service  provider  (PSP),  platform  of  interest  (POI),  and 
the  enabling/supporting  infrastructure  (ESI).  Each  of  these  elements  work  together 
through  a  series  of  level  agreements  with  the  goal  to  provide  high  quality  DS. 

1,  Product  vs.  Service 

DS  is  a  very  general  topic  and  has  several  meanings  depending  on  the  audience. 
In  order  to  classify  DS  as  a  product  or  a  service,  these  terms  must  first  be  defined. 

•  Product — tangible  and  discernible  items  or  assets  that  are  produced  or 
manufactured  by  an  organization 

•  Service — production  of  significant  intangible  benefit  that  satisfies  a 
requirement,  need,  condition,  obligation,  or  prerequisite 

While  these  definitions  are  distinct,  most  products  and  services  come  together 
bundled  as  one  and  execute  upon  each  other  to  deliver  an  enhanced  capability,  function, 
or  quality.  Eigure  20  details  how  the  concept  of  DS  can  rapidly  bounce  back  and  forth 
between  being  defined  as  a  service  and  as  a  product.  This  transformation  occurs  as  the 
concept  of  DS  matures  and  grows.  The  Y-axis  of  the  figure  is  related  to  concept  maturity. 
A  concept  new  in  its  life  cycle  starts  off  at  a  very  basic  level  (i.e.,  limited  knowledge  base 
and  no  discipline  experts).  As  the  concept  field  grows  and  expands,  a  predefined  service 
shifts  to  become  a  product  through  a  technological  or  process  enhancement.  This 
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enhancement  brings  added  knowledge  and  capability  to  the  concept  field  and  thus 
matures  the  concept  discipline.  It  can  be  expected  for  a  concept  to  shift  between  being  a 
product  or  service  as  the  concept  matures.  Once  a  concept  has  reached  its  full  maturity,  if 
possible,  the  concept  product  and  service  become  one  in  the  same.  This  would  be 
equivalent  to  having  a  system  become  what  is  known  as  an  “expert  system.”  This  system 
has  the  ability  not  only  to  emulate  the  decision-making  ability  of  a  human  concept 
discipline  expert,  but  it  also  has  the  ability  to  perform  self-repair  and  even  component 
replacement.  While  an  expert  system  like  this  is  many  years  away,  the  ability  for  a  DS 
expert  system  run  by  artificial  intelligence  with  part  fabrication  and  replacement  abilities 
via  three  dimensional  printing  may  be  possible  in  the  future. 
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2,  Legacy  and  Future  Platforms 

DS  can  be  applied  to  all  platforms,  regardless  of  current  life-cycle  phase.  While  it 


is  true  that  there  will  be  shortcomings  in  the  quality  and  detail  of  the  information 
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generated  by  the  DS  product  from  legacy  platforms,  it  still  may  be  useful  to  the  DS 
provider. 
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Figure  21 .  Legacy  Platform  Service  Interaction 


In  platforms  that  do  not  have  a  concept  component  “designed-in”  but  rather 
“bolted-on,”  also  known  as  a  legacy  platform,  the  interaction  between  the  concept  and 
platform  must  be  facilitated  by  a  service  link  between  the  two  (illustrated  in  Figure  21)  in 
order  to  deliver  the  concept  to  the  platform.  There  is  a  stark  difference  between  the 
legacy  platform  construct  and  the  future  platform  construct.  In  the  legacy  platform 
interaction,  the  service  provided  by  the  concept  to  the  platform  is: 

•  Rigid  -  With  a  “bolted-on”  concept,  providing  a  services  to  a  platform  after 
the  platform  design  has  been  completed,  concept  service  requirements  no 
longer  become  a  factor  and  must  adhere  to  platform  characteristic 
requirements  (interface,  security,  power,  form  factor). 

•  Fractured  -  With  a  “bolted-on”  concept  providing  services  to  a  platform, 
system  boundary  lines  are  very  distinct.  This  is  good  in  the  sense  that  system 
ownership  is  clean,  clear,  and  delineated,  but  offers  interface,  integration, 
security,  and  potential  ancillary  system  issues. 

•  Limited  -  With  a  “bolted-on”  concept  providing  services  to  a  platform  after 
the  platform  design  has  been  completed,  the  level  of  service  is  fixed  in  that  it 
can  only  provide  a  level  consistent  with  what  the  platform  can  provide  as  is,  at 
maximum. 

In  future  platforms,  the  concept  is  “designed-in.”  This  allows  the  concept  and  the 
platform  to  have  shared  requirements  and  be  fully  integrated  into  one  another,  as  denoted 
by  the  red  dashed  box  in  Figure  22,  thus  allowing  a  high  level  of  concept  service  to  be 
achieved. 
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Service 


Future  Platforms 

“Designed  -  In” 

•  Flexible 

•  Seamless 

•  Enhanced 


Figure  22. 


In  future  platform  interaction,  the  service  is  no  longer  provided  by  the  concept  to 
the  platform.  The  concept  service  is  executed  on  the  platform,  this  means  future  platform 
interaction  is: 

•  Flexible  -  With  a  “designed-in”  concept,  level  and  quality  of  concept  service 
metrics  can  be  tailored  to  a  setting  or  threshold  consistent  with  platform 
service  provider  /  user  requirements. 

•  Seamless  -  With  a  “designed- in”  concept,  the  boundary  line  between  the 
concept,  service,  and  platform  is  shared.  This  allows  for  greater 
communication  between  the  two  and  can  often  lead  to  better  security, 
interface,  and  product  requirements. 

•  Enhanced  -  With  a  “designed-in”  concept,  level  and  quality  of  concept  service 
being  executed  on  the  platform  is  greater  due  to  being  able  to  gain  access  to, 
gather,  process,  and  analyze  important  service  metrics  and  information. 

It  should  be  noted  that  another  significant  difference  between  these 
concept/platform  interactions  is  that  the  legacy  platforms  tend  to  be  more  dependent  on 
the  customer  initiating  and  executing  the  support  for  the  platform.  While  future  platforms 
will  still  include  the  customer  where  needed,  they  will  be  less  labor  intensive. 

3,  Distance  Support  Elements 

In  analyzing  the  current  organization  of  the  USN,  along  with  the  roles  and 
responsibilities  of  these  subsequent  support  organizations,  it  was  determined  that  a  simple 
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three-element  framework  should  be  created  to  take  advantage  of  this  organizational 
structure.  The  USN’s  support  organizations  are  funded  for  providing  a  capability  or 
service,  hence  the  use  of  service  level  and  operational  level  agreements  were  exploited  by 
this  framework.  For  completeness,  each  basic  element  was  covered,  but  the  focus  of  this 
framework  is  the  breakdown  of  the  POL 
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Figure  23.  DS  Application  Context  Diagram 


Figure  23  describes  the  application  context  of  DS  with  internal  factors,  enterprise 
ecosystems  entities,  and  global  environment  externalities  that  may  interact  with  providing 
quality  DS.  Starting  from  the  innermost  encompassed  item  on  the  DS  Application 
Context  Diagram,  each  item  is  explained  below. 

•  Quality  Distance  Support:  Goal  of  the  DS  framework,  the  quality  provided  via 
product  or  service  delivery  should  meet  or  exceed  that  of  the  customer  service 
requirements  or  needs. 
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•  Information  Integration  and  Data  Fusion  (I2DF):  Evidence  passed,  generated, 
and  shared  that  the  PSP,  POI,  and  ESI  collect,  verify,  record,  validate,  store, 
process,  filter,  log,  compress,  and  analyze  to  produce  quality  DS. 

•  Platform  Service  Provider  (PSP):  Organization  or  agent  that  provides  service, 
maintenance,  and  technical  support  to  the  POI,  its  customers,  and  users. 

•  Platform  of  Interest  (POI):  System  that  has  a  need  for  service. 

•  Enabling  /  Supporting  Infrastructure  (ESI):  Eacilities,  materials,  and  services 
necessary  to  store,  transmit,  or  receive  the  critical  information  needed  to 
execute  /  assist  a  function. 

o  Enable — give  someone  or  something  the  authority  or  means  to  do 
something 

o  Support — give  assistance  to,  help  or  aid 

•  Service  Level  Agreement  (SEA):  An  external  agreement  between  the  POI  and 
PSP,  POI  and  ESI,  and  PSP  and  ESI,  stipulating  client  service  requirements 
and  provider  service  delivery. 

•  People,  Process,  Technology:  Three  elements  that  make  up  successful  PSPs, 
ESIs,  and  POIs. 

•  Operational  Level  Agreement  (OLA):  An  internal  agreement  detailing  how 
various  functions  and  groups  within  an  element  plan  to  deliver  a  service  or 
package  of  services. 

•  Enterprise  Ecosystem:  Entities  separate  from  the  DS  products  and  services 
that  may  need  to  be  considered  or  adhered  to. 

•  Global  Environment:  Externalities  removed  from  the  Enterprise  Ecosystem 
that  may  influence  and  dictate  changes  to  DS  products  and  services. 


Eigure  24  shows,  in  a  simplified  fashion,  how  these  basic  elements  interact  with 
one  another.  Typically,  DS  between  the  PSP  and  the  POI  is  facilitated  by  the  ESI.  It 
should  be  noted  that  in  rare  cases,  DS  can  be  facilitated  between  the  PSP  and  the  POI 
without  the  use  of  an  ESI.  This  is  usually  found  on  the  POI  side  where  the  ESI  fails  to 
meet  PSP  requirements  or  the  data  provided  from  the  POI  is  non-mission  critical. 
Examples  of  this  include  a  POI  where  the  data  being  generated  is  too  great  for  the  ESI  to 
transmit  in  a  timely  fashion  or  the  data  from  the  POI  is  not  time  critical  and  can  be 
analyzed  “stale.” 

In  general,  the  POI  is  the  product  that  the  customer  is  using  to  perform  a  given 


task.  As  this  POI  is  executing  the  desired  task,  data  is  generated  that  is  then  sent  back  to 
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the  PSP  via  the  ESI.  The  ESFs  main  funetion  in  performing  DS  is  ensuring  end-to-end 
eommunication  between  the  PSP  and  POL 


Eigure  24.  The  Three  Basie  Elements  of  Distanee  Support  (leons  from  Elatieon  2014) 


Each  of  these  elements  has  ownership  of  their  respective  domain.  That  is,  no 
element  may  cross  into  another  element’s  domain  without  proper  authorization.  The 
concurrence  that  allows  cross-domain  transits  are  known  as  service  level  agreements 
(SLAs).  SLAs  are  contracts  between  elements  that  detail  the  level  of  service  expected 
from  a  provider.  In  this  case,  there  would  be  several  SLAs: 

•  PSP  to  POI:  The  PSP  would  have  a  SLA  with  the  POI  that  would  detail  the 
quality  of  service  (support). 

•  ESI  to  PSP:  The  ESI  would  have  a  SLA  with  the  PSP  that  would  detail  the 
quality  of  service  (bandwidth  throughput,  link  availability). 

•  ESI  to  POI:  In  many  cases  the  ESI  to  PSP  SLA  would  cover  this  case,  but 
there  are  times  when  the  two  can  be  separated  and  thus  require  another  SLA 
between  the  two  elements. 

A  good  example  of  SLAs  in  action  is  residential  Internet  access  with  subscription 

video  streaming  services.  Typically  the  customer  has  a  SLA  with  the  ISP  (i.e.,  Comcast  / 

65 


Time  Warner)  that  details  the  expeeted  speed  and  service  availability  of  the  network 
connection.  The  customer  also  has  a  separate  SLA  with  a  subscription  video  streaming 
service  (Netflix/Hulu)  that  details  how  many  shows  he  can  watch  or  how  often  they  can 
watch  episodes.  In  addition  to  these  SLAs,  separate  SLAs  are  struck  between  the  ISP  and 
subscription  video  streaming  services  that  can  detail  geographic  service  delivery  or  total 
service  bandwidth. 


Figure  25.  Service  Level  Agreements  between  the  Three  Elements  of  Distance 

Support  (Icons  from  Flaticon  2014) 

In  Figure  25,  the  green  arrows  stipulate  client  service  requirements,  while  the  blue 
arrows  stipulate  provider  service  delivery.  These  SLAs  can  be  renegotiated  after  the 
previous  service  contract  has  expired.  It  is  important  to  negotiate  an  SLA  frequently; 
technology  and  capability  needs  often  outpace  the  constraints  of  an  SLA  before  the  SLA 
expires.  A  separate  SLA  with  each  entity  is  not  always  required.  Blanket  SLAs  can  be 
authored  to  cover  more  than  one  element  if  deemed  practical.  The  most  crucial  SLA  is 
the  one  that  ties  the  PSP  to  the  POL  Without  this  SLA,  support  (distance  or  not)  does  not 
exist. 

A  complete  SLA  should  have  the  following  sections  listed  in  Table  7. 
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Table  7.  SLA  and  OLA  Elements 


Section  Name 

Purpose 

Agieement  Ovei'view 

Details  the  agieement  in  general.  States  its  validity  as 
well  as  endorsement  by  the  stakeholders. 

Goals  and  Objectives 

States  the  piupose  of  the  agieement  as  well  as  the  goal. 
Typical  objectives  include:  (1)  Provide  clear  reference 
to  seivice  ownership,  accoimtability,  roles  and  /  or 
responsibilities.  (2)  Present  a  clear',  concise  and 
measmable  description  of  service  provision  to  the 
customer.  (3)  Match  perceptions  of  expected  service 
provision  with  actual  service  support  and  delivei'y. 

Stakeholders 

List  all  parties  that  enter  mto  the  agreement.  Delineate 
between  the  seivice  provider  and  the  customer. 

Periodic  Review 

Agreements  should  state  the  effective  date,  the 
business  relationship  manager  (“document  owner”), 
review  cycle  (6-12  months),  previous  review  date,  and 
the  next  fiitme  review  date. 

Seiwice  Scope 

List  of  services  that  will  be  offered  to  the  customer. 

Customer  Requirements 

Customer  responsibilities  and  /  or  requirements. 

Seivice  Provider 

Requirements 

Seivice  Provider  responsibilities  and  /  or  requhements. 

Service  Assumptions 

Assumptions  related  to  in-scope  services. 

Seiwice  Management 

Management,  maintenance,  and  support  of  seivice. 

Seivice  Availability 

Service  availability  parameters. 

Service  Requests 

Details  how  seivice  request  from  the  customer  will  be 
handles  and  the  associated  priority  they  will  be 
assigned. 

Seivice  Performance 

Volume  and  Speed  metrics. 

Seivice  Measiuement 

Definitions  on  how  metrics  will  be  collected  and 
calculated. 

Service  Penalty 

Addr  esses  ramifications  if  seivice  provider  /  customer 
violate  SLA  terms. 
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Within  each  element’s  domain  there  exists  another  agreement  called  an 
operational  level  agreement  (OLA)  as  shown  in  Figure  26.  An  OLA  is  a  contract  that 
details  how  various  functions  and  groups  within  an  element  plan  to  deliver  a  service  or 
package  of  services.  Each  basic  element  typically  has  at  least  one  OLA.  The  simplest 
form  of  an  OLA  in  action  is  when  a  business  sets  priorities.  By  setting  a  priority,  the 
business  has  dictated  how  its  functions  will  operate  with  one  another  concerning  topics. 
OLA  structure  mirrors  that  of  an  SLA,  with  the  exception  that  it  has  a  greater  focus  on 
change  requests,  incident  management,  maintenance  changes  /  requests,  and  reporting. 


Platform  Service  Provider  (PSP) 


Figure  26.  Operational  Level  Agreements  internal  to  Platform  Service  Provider 

(Icons  from  Flaticon  2014) 
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Enabling  /  Support 
Infrastructure  (ESI) 


LPlatfbnn^fInterest_^PO^ 

Figure  27.  Platform  Service  Provider  DS  Walkthrough  (Icons  from  Flaticon  2014) 


Figure  27  shows  an  example  of  how  a  PSP  and  POI  interact  by  highlighting  the 
data  and  service  contract  path.  The  steps  have  been  numbered  and  listed  in  Table  8  for 
ease  of  comprehension. 
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Table  8.  Data  and  Semce  Contract  Paths  for  PSP 


Location 

Point 

Next  Move 

Action 

Bottom  right 
of  figure 

1 

The  Distance  Support  X,  (DSX)  detects  a  fault  in  the  X 
system  that  caimot  be  resolved. 

1 

2 

An  event  flag  is  triggered  and  the  DSX  decides  that  DS 
should  be  sought  for  a  solution. 

2 

3 

The  fault  message  is  prepared  to  be  sent  through  the  ESI 
to  the  PSP. 

27 

The  fault  message  data  passes  thiougli  the  ESI  SLA,  but 
the  SLA  with  the  PSP  is  used  to  perfonn  the  seiwice 
contract  action. 

3 

4 

Using  the  SLA  between  the  POI  and  the  ESI,  the  fault 
message  enters  the  ESI  domain. 

4 

5 

The  fault  message  is  transpoifed  tluough  the  ESI. 

5 

6 

Using  the  SLA  between  the  ESI  and  the  PSP,  the  fault 
message  enters  the  PSP  domain. 

6 

7 

The  fault  message  is  routed  to  the  PSP’s  “helpdesk.” 

7 

8 

The  fault  message  is  entered  in  the  system  and  assigned 
a  tracking  number  and  reclassified  as  a  “help  ticket.” 

8 

9 

Following  the  giridelines  m  the  OLA,  the  “helpdesk” 
sends  the  “help  ticket”  to  the  multi-tiered  technical 
support  groirp  starting  at  tier  one. 

9 

10 

The  “help  ticket”  is  received  by  the  tier  one  teclurical 
sirpport  staff  and  research  for  a  sohrtiorr. 

10 

11 

The  tier  one  technical  sirpport  staff  research  provided  a 
solution. 

12 

The  tier  one  technical  support  staff  research  was  imable 
to  provide  a  solution.  The  “help  ticket”  is  elevated  to  tier 
two  technical  support  following  the  giridelines  in  the 
OLA. 

11 

18 

The  technical  solution  foimd  is  updated  and  recorded  in 
the  DS  Krrowledge  Management  Library  to  help  build  a 

70 


Location 

Point 

Next  Move 

Action 

better  knowledge  database. 

12 

13 

The  “help  ticket”  is  received  by  the  tier  two  technical 
support  staff  and  research  for  a  solution. 

13 

14 

The  tier  two  technical  support  staff  research  was  unable 
to  provide  a  solution.  The  “help  ticket”  is  elevated  to  tier 
three  technical  suppoif  following  the  guidelines  in  the 
OLA. 

18 

The  technical  solution  foimd  is  updated  and  recorded  in 
the  DS  Knowledge  Management  Library  to  help  build  a 
better  knowledge  database. 

14 

15 

The  “help  ticket”  is  received  by  the  tier  three  technical 
support  staff  and  research  for  a  sohrtion. 

15 

16 

The  tier  thr  ee  technical  support  staff  research  was 
imable  to  provide  a  solution.  The  “help  ticket”  is 
elevated  to  tier  foin  /  OEM  technical  support  following 
the  giridelines  in  the  OLA. 

18 

The  technical  sohrtion  foimd  is  updated  and  recorded  in 
the  DS  Knowledge  Management  Library  to  help  build  a 
better  knowledge  database. 

16 

17 

The  tier  foiu'  /  OEM  technical  support  staff  research  was 
able  to  provide  a  sohrtion.  Otherwise  the  OEM  will 
ensme  the  prodirct  is  fixed  upon  new  version  release. 

17 

18 

The  technical  solution  foimd  is  updated  and  recorded  in 
the  DS  Knowledge  Management  Library  to  help  build  a 
better  knowledge  database. 

20 

The  tier  foiu'  /  OEM  technical  support  prepare  for  site 
visit  due  to  the  technical  complexity  of  the  issue. 

18 

19 

The  “help  ticket”  is  closed  out  with  the  status  and 
outcome  of  the  support  inquiry. 

19 

22 

The  technical  solution  is  routed  from  the  “help  desk” 
througlr  the  PSP. 

20 

21 

The  tier  foiu'  /  OEM  technical  support  travel  for  site  visit 
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Location 

Point 

Next  Move 

Action 

dire  to  the  teclmical  complexity  of  the  issue. 

21 

COMPLETE 

Technical  solution  resolved. 

22 

23 

The  technical  solution  is  roirted  through  the  PSP. 

28 

The  technical  solution  passes  through  the  ESI  SLA,  but 
the  SLA  with  the  PSP  is  irsed  to  perforin  the  service 
contract  delivery. 

23 

24 

Using  the  SLA  between  the  PSP  and  the  ESI,  the  fault 
message  enters  the  ESI  domain. 

24 

25 

The  technical  solirtiorr  is  roirted  through  the  ESI. 

25 

26 

Using  the  SLA  between  the  ESI  and  the  POI,  the  fault 
message  enters  the  POI  domain. 

26 

21 

The  technical  solution  is  validated  and  verified. 

27 

6 

The  fault  message  data  passes  througli  the  ESI  SLA,  but 
the  SLA  with  the  PSP  is  used  to  perforin  the  service 
contract  action. 

28 

26 

The  technical  solution  passes  through  the  ESI  SLA,  but 
the  SLA  with  the  PSP  is  used  to  perforin  the  service 
contract  delivery. 

In  the  previous  walkthrough,  the  original  message  fault  was  routed  to  a 
“helpdesk”  and  then  routed  to  the  multi-tiered  technical  support  group.  In  the  previoirs 
chapter,  wait  times  were  compared  with  each  other  to  show  how  effective  phone  tree 
menus  could  be  constrircted.  While  the  mirlti-tiered  teclurical  support  group  is  not  a 
phone  tree,  the  same  principles  apply.  As  illustrated  in  Figirre  28,  Figrue  29,  and  Figiue 
30,  there  are  five  maiir  types  of  waiting  lines,  or  iir  this  case,  phone  menu  systems  in  rrse: 
(1)  sirrgle-server,  single-phase,  (2)  single-seiwer,  multiphase,  (3)  multi-sei'ver,  single-lirre, 
single-phase,  (4)  multi-server,  mrrltiline,  single-phase,  and  (5)  mirlti-server,  mrrlti-phase. 
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Single-Server,  Single-Phase 

Single-Server,  Multiphase 


I 


Figure  28.  Waiting  Line  Examples  (leons  from  Flatieon  2014) 

Single-server  waiting  line  models  ean  be  used  to  gain  valuable  metrics  about 
service  organization  and  efficiency.  When  modeling  single-server  waiting  line  models, 
the  following  is  assumed  (Unknown  2010): 

•  Customers  arrive  by  a  Poisson  distribution  with  a  mean  arrival  rate  of  A 

•  Time  between  additional  customer  arrivals  follows  an  exponential  distribution 
with  an  average  of  1/1 

•  Customer  service  rate  also  follows  a  Poisson  distribution  with  a  mean  service 
rate  of  /r 

•  Service  time  for  one  customer  follows  an  exponential  distribution  with  an 
average  of  1/jU 
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Multi-Server,  Single-Line,  Single-Phase 


I  e  ^ 


Figure  29.  Waiting  Line  Examples  Continued  (Icons  from  Flaticon  2014) 


Using  the  accepted  givens  above,  the  following  waiting  line  system  characteristics 
can  be  calculated  as  follows  (Unknown  2010): 

•  P  ~  ~~  average  utilization  of  the  system 

•  L  =  =  average  number  of  customers  in  the  service  system 

[l—A 


Lq  =  pL  =  average  number  of  customers  waiting  in  line 

'I 

W  =  — -  =  average  time  spent  waiting  in  the  system,  including  service 

H-A 


•  Wq  =  pW=  average  time  spent  waiting  in  line 

•  Pji  =  (1  —  p)p”  =  probability  that  n  customers  are  in  the  service  system  at  a 
given  time 

The  service  rate  must  be  greater  than  the  arrival  rate,  p>  X. 
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Figure  30.  Waiting  Line  Examples  Continued  (Icons  from  Flaticon  2014) 

Multi- Server  waiting  line  models  can  also  be  modeled  using  the  same  given 
assumptions  that  were  used  for  the  single  server  waiting  line  models.  Using  the  accepted 
givens  above,  the  following  waiting  line  system  characteristics  can  be  calculated  as 
follows  (Unknown  2010): 

•  s  =  the  number  of  servers  in  the  system 

•  P  “  ~  “  average  utilization  of  the  system 

•  Pq  —  [Zn=o  (i^)]  ^  probability  that  no  customers  are  in 

the  system 

•  Lq  —  ^  average  number  of  customers  waiting  in  line 

•  ^0  average  time  spent  waiting  in  line 

^  A 

1 

•  W  =  Wq  +  ~  -  average  time  spent  in  the  system,  including  service 

•  L  =  AW=  average  number  of  customers  in  the  service  system 
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Pn  = 


n\ 


Pq  for  n  <  s 

=  probability  the  n  customers  are  in  the  system  at  a 

Pq  for  n>  s 


given  time 

The  service  rate  must  be  greater  than  the  arrival  rate,  s/r  >  A. 


Figure  3 1 .  Enabling/Supporting  Infrastructure  DS  Walkthrough  (Icons  from  Flaticon 

2014) 


Figure  3 1  shows  an  example  of  how  the  ESI  interacts  with  the  other  DS  elements 
by  highlighting  the  data  and  service  contract  path.  The  steps  have  been  numbered  and 
listed  in  Table  9  for  ease  of  comprehension. 
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Table  9.  Data  aiid  Semce  Contract  Paths  for  ESI 


Location 

Point 

Next  Move 

Action 

Bottom  right 
of  figiue 

1 

The  Distance  Support  X,  DSX  detects  a  fault  in  the  X 
system  that  cannot  be  resolved. 

1 

2 

An  event  flag  is  triggered  and  the  DSX  decides  that  DS 
should  be  souglit  for  a  solution. 

3 

The  fault  message  data  passes  through  the  ESI  SLA,  but 
the  SLA  with  the  PSP  is  used  to  perfoim  the  semce 
coutiact  action. 

2 

5 

Using  the  SLA  between  the  POI  and  the  ESI,  the  fault 
message  enters  the  ESI  domain. 

3 

4 

The  fault  message  data  passes  through  the  ESI  SLA,  but 
the  SLA  with  the  PSP  is  used  to  perfoim  the  service 
coutiact  action. 

4 

17 

The  PSP  researches  the  POI  inquuy. 

5 

6 

The  fault  message  is  routed  through  the  ESI’s  edge 
network  connections  in  guidance  with  the  OLA. 

6 

7 

The  fault  message  is  routed  through  the  ESFs  DMZ  and 
to  its  LAN  in  guidance  with  the  OLA. 

7 

8 

The  fault  message  is  routed  tluougli  the  ESI’s  LAN  and 
to  its  NAP  in  guidance  with  the  OLA. 

8 

9 

The  fault  message  is  routed  tlirough  the  ESTs  NAP  and 
to  its  NOC  in  guidance  with  the  OLA. 

9 

10 

The  fault  message  is  routed  thiough  the  ESFs  NOC  in 
guidance  with  the  OLA. 

10 

11 

The  fault  message  is  routed  through  the  ESFs  NOC  and 
to  its  NAP  in  guidance  with  the  OLA. 

11 

12 

The  fault  message  is  routed  tluough  the  ESFs  NAP  and 
to  its  LAN  in  guidance  with  the  OLA. 

12 

13 

The  fault  message  is  routed  tluough  the  ESFs  LAN  and 
to  its  DMZ  in  guidance  with  the  OLA. 
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Location 

Point 

Next  Move 

Action 

13 

14 

The  fault  message  is  routed  through  the  ESFs  edge 
network  comiections  in  guidance  with  the  OLA. 

14 

15 

Using  the  SLA  between  the  ESI  and  the  PSP,  the  fault 
message  enters  the  PSP  domain. 

15 

17 

The  PSP  researches  the  POI  inquuy. 

16 

19 

The  technical  solution  data  passes  through  the  ESI  SLA, 
but  the  SLA  with  the  PSP  is  used  to  perform  the  service 
contract  action. 

17 

18 

A  technical  sohrtion  is  foimd  and  is  sent  back  to  the  POL 

18 

16 

The  teclurical  solution  data  passes  through  the  ESI  SLA, 
but  the  SLA  with  the  PSP  is  rrsed  to  perform  the  service 
contract  action. 

20 

Using  the  SLA  between  the  ESI  and  the  PSP,  the 
teclmical  solution  prepares  to  enter  the  PSP  domain. 

19 

32 

The  technical  solution  data  passes  throirgh  the  ESI  SLA, 
but  the  SLA  with  the  PSP  is  rrsed  to  perform  the  service 
contract  action. 

20 

21 

Using  the  SLA  between  the  ESI  and  the  PSP,  the 
teclmical  sohrtion  enters  the  PSP  domain. 

21 

22 

The  technical  solution  is  roirted  through  the  ESI’s  edge 
network  cormections  in  guidance  with  the  OLA. 

22 

23 

The  technical  solution  is  routed  throirgh  the  ESFs  DMZ 
and  to  its  LAN  in  giridance  with  the  OLA. 

23 

24 

The  teclmical  solution  is  routed  tluougli  the  ESFs  LAN 
and  to  its  NAP  in  guidance  with  the  OLA. 

24 

25 

The  teclmical  solution  is  routed  tluough  the  ESFs  NAP 
and  to  its  NOC  in  guidance  with  the  OLA. 

25 

26 

The  technical  sohrtion  is  routed  through  the  ESFs  NOC 
in  guidance  with  the  OLA. 

26 

27 

The  teclmical  solution  is  routed  tluougli  the  ESFs  NOC 
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Location 

Point 

Next  Move 

Action 

and  to  its  NAP  m  guidance  with  the  OLA. 

27 

28 

The  teclmical  solution  is  routed  through  the  ESTs  NAP 
and  to  its  LAN  in  guidance  with  the  OLA. 

28 

29 

The  technical  solution  is  routed  through  the  ESFs  LAN 
and  to  its  DMZ  m  guidance  with  the  OLA. 

29 

30 

The  technical  solution  is  routed  through  the  ESFs  edge 
network  connections  in  guidance  with  the  OLA. 

30 

31 

Using  the  SLA  between  the  POI  and  the  ESI,  the  fault 
message  enters  the  POI  domain. 

31 

32 

The  technical  solution  passes  through  the  POI. 

32 

COMPLETE 

Teclmical  solution  resolved. 

•  POI  is  the  Independent  Platform 


•  POI  is  the  Guest  Platform  contained  within  the 
..  Host  Platform. 


Guest  Platform 

•  Incomplete  data  rights 

•  Dependent  on  “Hotel  Ser\dces” 

•  SLA  with  Host  Platform 

•  Resides  in  a  subsystem  hierarchy 

•  Typically  provide  a  function 


Independent  Platform 

•  Not  subject  to  control  by  others 

•  Not  requiring  or  relying  on  someone 

•  Ownership  of  “Hotel  Services” 


Platfonii  of  Interest  (POI) 


Enabling  Support 
In&astiuctu£e_^ES^ 


Figure  32.  Platfonu  of  Interest  DS  Walkthrough  (Icons  from  Flaticon  2014) 
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Following  the  same  methodology  from  the  previous  two  walkthrough  figures, 
Figure  32  conveys  the  same  concept  showing  the  connections  and  interactions  between 
the  three  basic  elements  of  DS.  The  main  difference  with  this  walkthrough  example  is  the 
attention  to  detail  in  explaining  how  the  POI  can  be  classified  as  an  independent  platform 
vs.  guest  platform  contained  within  a  host  platform.  The  POI  had  to  be  delineated  and 
subdivided  to  account  for  POI  that  resides  within  another  platform.  If  the  POI  is  not 
subject  to  control  by  other  platforms,  it  does  not  require  or  rely  on  supporting  platforms 
and  has  complete  ownership  of  its  “hotel  services.”  The  POI  is  simply  the  independent 
platform  itself.  If  the  POI  has  incomplete  data  rights,  relies  on  a  support  structure  for 
“hotel  services,”  has  a  SLA  with  a  host  platform,  resides  in  a  subsystem  hierarchy,  or 
provides  a  function  to  a  higher  order  system,  the  POI  is  classified  as  a  guest  platform 
contained  within  a  host  platform. 


Host  Platform 


Platform  Serv  ice  Provider 
(PSP) 


Host  Platform 

Host  Platform 

Hotel  and  Support 

Enabling  ■  Support 

Services 

Infrastructure  (ESI) 

Guest  Platform 

1  1 

Platfomi  of  Interest  (POI) 

1  f 

i  1 

1  1 

1  f 

Enabling  Support 
Infrastructure  (ESI) 

Figure  33.  Platform  of  Interest  Guest  and  Host  Interaction  DS  Walkthrough  (Icons 

from  Flaticon  2014) 
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Figure  33  shows  the  different  types  of  host  and  guest  platform  interaetions.  The 
prominent  aspeet  of  the  interaetion  diagram  is  the  ereation  of  a  new  SLA  between  the 
guest  and  host  platforms.  Sinee  the  guest  platform  is  dependent  on  the  host  platform  for 
“hotel  serviees,”  as  well  as  for  network  eonneetivity  to  reaeh  the  PSP  via  the  ESI,  the 
guest  platform  must  develop  two  SLAs,  one  for  the  support  services  and  another  for 
access  to  the  host  platform’s  ESI. 

Eigure  33  also  sheds  light  on  the  various  ways  DSX  (Distance  Support  X,  where 
X  is  the  system  name)  can  be  configured.  This  is  detailed  in  the  next  section. 

4,  DSX  for  the  POI 

DSX  configuration  depends  on  the  POI,  its  interactions,  support  systems,  life- 
cycle  phase,  as  well  as  the  technologies  available.  The  main  DSX  configurations 
recommended  are  as  follows: 

•  Integrated — DSX  is  designed  into  the  system,  single-point  all  inclusive 

•  Encompassing — DSX  is  designed  to  fit  around  an  existing  system  (usually 
used  for  legacy  systems),  single-point  semi  inclusive 

•  Distributed — DSX  has  a  central  node  where  distributed  DSX  nodes  report, 
multipoint  all/semi  inclusive 


..b 

CC 

a, 

cz 

u 

</i 

o 

U 


Scalability  and  Complexity 


Figure  34.  DSX  Configurations  in  terms  of  Cost,  Capability,  Scalability,  and 

Complexity 
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When  the  DSX  configurations  are  compared  to  each  other  in  terms  of  cost, 
capability,  scalability,  and  complexity,  the  tradeoffs  become  clear.  In  Figure  34,  the  four 
DSX  configurations  were  plotted  for  a  fictional  system.  A  “Minimum  Data  Picture 
Completeness  Threshold”  line  was  then  plotted  across  the  chart.  This  line  represents  the 
minimum  amount  of  data  that  needs  to  be  collected  either  from  multiple  sources  or  a 
single  source  to  provide  meaningful  information  integration  and  data  fusion  (I2DF)  so 
that  a  quality  DS  product  or  service  can  be  delivered.  This  line  and  the  DSX 
configurations  will  differ  from  system  to  system. 


Before  the  first  function  of  the  DSX  can  be  assessed,  the  POI  must  be  analyzed  to 
decide  which  DSX  configuration  fits  best,  as  well  as  the  sensor  network  topology  to  use. 
Each  network  topology  (wired  or  wireless),  like  each  DSX  configuration,  has  advantages 

and  disadvantages.  These  differences  should  be  weighed  against  the  types  of  sensors  that 
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will  be  used  within  the  sensor  network.  Some  of  these  are  illustrated  in  Figure  35  and 
discussed  below  (CISCO  Inc.): 

•  Bus  Network:  A  bus  network  benefits  from  being  easy  to  connect  and  requires 
little  cable.  Problems  arise  if  the  main  bus  backbone  is  damaged  as  it  will  shut 
the  network  down  and  is  difficult  to  troubleshoot  if  the  network  is  vast. 

•  Ring  Network:  A  ring  network  benefits  from  being  predictable  in  terms  of 
data  path  and  the  independent  connections  make  the  network  simple  to 
troubleshoot.  Problems  arise  as  the  network  grows  in  size  due  to 
communications  delays  being  proportional  to  the  number  of  nodes  in  the 
network  and  shared  bandwidth  resources. 

•  Fully  Connected  Network:  A  fully  connected  network  benefits  from  multiple 
link  redundancy  and  the  ability  to  keep  network  traffic  at  a  minimum. 
Problems  arise  when  the  number  of  network  nodes  grow  due  to  the  amount  of 
cable  needed  to  link  all  of  the  nodes  and  the  sheer  amount  of  connections 
needed  (the  number  of  connections  grows  quadratically  with  c  =  (n(n  — 

l))/2). 

•  Overlay  Network:  An  overlay  network  benefits  in  that  the  network  itself  can 
be  defined  by  the  user  or  data  preference  through  virtual  or  logical  links. 
Problems  arise  when  complicated  preferences  distribute  resources  and  load 
balance  network  traffic  by  priority  making  lower  priority  services  unusable. 

•  Star  Network:  A  star  network  benefits  from  centralization  of  the  center  hub 
and  increased  network  performance.  The  centralization  of  the  hub  allows  for 
network  inspection  of  traffic  and  usually  has  a  high  utilization  rate  allowing 
for  the  hub  nodes  to  limit  the  number  of  connections  to  them.  Problems  arise 
from  the  lack  of  a  robust  center  hub  causing  slow  throughput  speeds.  The 
center  hub  is  a  single-point  of  failure. 

•  Mesh  Network:  A  mesh  network  benefits  from  being  a  flexible  network  that 
can  grow  and  shrink  over  time.  Problems  arise  when  these  flexible  networks 
are  changed  without  proper  network  mapping,  leaving  parts  of  the  mesh 
network  unconnected  or  overburdened. 

•  Tree  Network:  A  tree  network  benefits  from  being  scalable  as  well  as  having 
fairly  fast  troubleshooting  isolation  times.  Problems  arise  when  maintenance 
or  failure  of  a  main  backbone  occurs,  leaving  the  network  severely  degraded 
until  it  is  repaired. 

•  Linear  Network:  A  linear  network  benefits  from  being  simple  to  set  up  as  well 
as  low  cost.  Problems  arise  if  any  link  between  two  nodes  fail  or  when  the  size 
of  the  network  grows  do  to  communication  delays  from  one  side  of  the 
network  to  the  other. 

After  the  proper  POI  has  been  identified,  classified  as  an  Independent  Platform  or 

a  Guest  Platform  contained  within  a  Host  Platform,  DSX  configuration  chosen,  and 
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sensor  network  topology  selected,  the  POI  is  ready  to  begin  sensor  type  selection.  The 
PSP  SMEs  who  have  a  great  understanding  of  the  POI  system  and  the 
capabilities/limitations  of  PSP  resources  should  carry  out  sensor  selection. 

Figure  36  gives  different  types  of  materials  that  are  used  to  build  sensors  based  on 
their  monitoring  environment.  Sensors  should  be  chosen  to  meet  the  environmental 
constraints  and  characteristics  to  ensure  quality  data  collection. 


Figure  36.  Sensor  Materials  (Meijer  2008,  6) 


Figure  37  shows  common  parameters  that  define  sensor  functionality  as  sorted  by 
type.  The  number  and  type  of  sensors  chosen  should  be  consistent  with  the  DSX 
configuration,  sensor  network  topology,  sensor  environment,  and  meet  or  exceed  the 
minimum  data  picture  completeness  threshold. 
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Figure  37.  Sensor  Parameters  (from  Meijer  2008,  7) 


Sensor  sampling  frequency  is  dependent  on  the  parameter  being  monitored,  its 
volatility,  along  with  its  criticality  to  function.  The  monitoring  of  safety  systems  will 
require  a  higher  than  average  sampling  frequency  due  to  the  impact  of  a  hazard  that  may 
result  between  sample  extractions  from  a  continuous  signal.  Per  the  Nyquist-Shannon 
sampling  theorem  (Nyquist  and  Shannon  2012),  a  sensor  should  sample  a  signal  at  twice 
its  maximum  frequency  within  the  bandlimited  signal.  If  a  function  x(t)  contains  no 
frequencies  higher  than  B  hertz,  it  is  completely  resolved  by  giving  its  ordinates  at  a 

series  of  points  spaced  at  — . 
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1 

If  monitoring  at  the  Nyquist  rate  (25)  or  the  Nyquist  frequency  —  is  not  possible, 

other  signal  sampling  techniques  exists.  One  such  technique  is  known  as  compressive 
sampling  or  compressive  sensing.  Compressive  sampling  theory  states  that  signals  can  be 
recovered  and  potentially  acquired  with  far  fewer  samples  than  traditional  methods,  like 
that  of  the  Nyquist-Shannon  sampling  theorem  (Candes  and  Wakin  2008).  Compressive 
sampling  relies  on  two  key  themes:  sparsity  and  incoherence.  Sparsity  deals  with  the  fact 
that  a  continuous  time  signal  is  much  less  than  its  bandwidth  or  a  discrete-time  signal’s 
number  of  degrees  of  freedom  is  much  smaller  than  its  length  (Candes  and  Wakin  2008). 
Incoherence  shows  the  degree  of  correlation  between  the  objects  having  a  sparse 
representation  in  the  domain  they  are  acquired  between  time  and  frequency  (Candes  and 
Wakin  2008).  If  a  signal  meets  these  two  conditions,  it  may  be  a  candidate  for 
compressive  sampling.  Compressive  sampling  has  shown  to  reduce  the  number  of 
samples  needed  to  be  a  4-to-l  ratio,  one  needs  four  incoherent  samples  per  unknown 
nonzero  term  (Candes  and  Wakin  2008). 

Attention  to  sensor  signal  noise  needs  to  be  taken  into  account  as  well.  Common 
methods  to  reduce  signal  noise  include  the  following: 

•  Reject  DC  common-mode  voltage  (National  Instruments  2008) 

•  Reject  AC  common-mode  voltage  (National  Instruments  2008) 

•  Break  ground  loops  (National  Instruments  2008) 

•  Use  4-20  mA  current  loops  (National  Instruments  2008) 

•  Use  24  V  digital  logic  (National  Instruments  2008) 

•  Low-pass  frequency  response  filter 

•  High-pass  frequency  response  filter 

•  Band-pass  frequency  response  filter 

•  Band-stop  frequency  response  filter 

•  Notch  frequency  response  filter 

•  Comb  frequency  response  filter 

•  All-pass  frequency  response  filter 

•  Cutoff  frequency  response  filter 

•  Roll-off  frequency  response  filter 
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•  Transition  frequency  response  filter 

•  Ripple  frequency  response  filter 

•  Butterworth  filter 

•  Chebystiev  filter  (Type  I  and  II) 

•  Bessel  filter 

•  Elliptic  filter 

•  Optimum  “L”  filter 

•  Gaussian  filter 

•  Hourglass  filter 

•  Raised-cosine  filter 

•  Constant  k  filter 

•  M-derived  filter 

•  Infinite  impulse  response  filter 

•  Finite  impulse  response  filter 
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Figure  38.  Generic  DS  Functional  Allocation  Example  (Icons  from  Flaticon  2014) 


The  DSX  module  itself,  independent  or  guest  platform,  will  consist  of  the  same 
functions.  The  functions  and  their  definitions,  are  shown  in  Figure  38  and  listed  below. 

•  Collect — the  POI  will  have  the  ability  to  collect  the  data  of  interest  as  decided 
by  the  PSP  and  User  by  means  of  self-test,  built-in  test  (BIT),  or  component 
sensorization 

•  Verify — the  data  collected  will  be  verified  to  ensure  it  is  being  collected 
correctly 

•  Record — data  is  stored  in  a  short  term  memory  to  guard  against  corruption 
before  data  validation 

•  Validate — data  is  checked  for  correctness  and  meaningfulness 

•  Store —  data  is  then  written  to  long  term  storage  and  backed  up 

•  Process — data  is  analyzed  for  trends,  flags,  or  other  useful  information  for  the 
PSP  and  User 

•  Filter* — the  results  from  the  process  step  are  filtered  for  content  relevance 
and  importance 
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•  Log* — data  from  the  filtered  step  is  logged  to  ereate  a  reeord  of 
eommunication  in  which  an  event  has  happened  or  triggered  over  a  set  period 
of  time 

•  Compress* — important  data  and  logs  are  encoded  and  reduced  in  size  to  be 
transported  to  the  PSP 

•  Action — results  from  the  process  data  step  are  used  to  send  commands, 
actions,  or  triggers  to  the  User/Customer  or  PSP  for  execution 

In  the  steps  above,  the  steps  with  an  (*)  beside  them  denote  actions  required  for 
transportation  of  data  through  the  ESI  to  the  PSP  only.  Another  important  object  of  note 
is  the  SLA  with  user/customer  inset.  The  user/customer  is  typically  always  a  part  of  the 
support  process  and  is  usually  the  first  line  of  defense.  Figure  39  thru  Figure  47  detail 
each  function  of  the  DSX  modules 
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Figure  39.  DSX  Sensor  Network  Decision  Flow 
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Figure  40.  DSX  Collect  Data  Decision  Flow 
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Figure  41 .  DSX  Verify  Data  Decision  Flow 
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Figure  42.  DSX  Record  Data  Decision  Flow 


Figure  43.  DSX  Validate  Data  Decision  Flow 
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I 

I  From  Store  Data 
I  Function 


Figure  44.  DSX  Process  Data  Decision  Flow 


94 


I 

I  From  Process  Data 
I  Function 

I _ 


I 

I 

I 


Figure  45.  DSX  Filter  Data  Decision  Flow 
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Figure  46.  DSX  Log  Data  Decision  Flow 
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Figure  47.  DSX  Compress  Data  Decision  Flow 
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c. 


STAKEHOLDER  ANALYSIS 


Stakeholders  for  this  capstone  were  inteiviewed  and  categorized  under  the  three 
basic  elements  of  DS:  PSP,  ESI,  and  POI  as  indicated  in  Table  10.  While  the  Naval 
Postgraduate  School  (NPS)  has  an  interest  in  using  this  capstone  to  infoini  instruction 
and  guide  follow-on  research  to  enhance  the  skills  of  the  total  workforce,  it  did  not  fall 
into  one  of  the  three  basic  elements  of  DS  and  thus  was  categorized  as  “administrative.” 


Table  10.  Stakeholder  Categories 


Stakeholder 

Category 

Naval  Postgraduate  School  (NPS) 

Admuiistrative 

PMS  405  -  Directed  Energy  and  Electric  Weapon  Systems 

Program  Office 

POI 

Office  of  Naval  Research  (ONR) 

ESI 

NSWC  PHD  -  Office  of  Engineering  and  Technology  (OET) 

PSP 

NSWC  PHD  -  Distance  Sirpport  Advocacy  Office 

PSP 

Naval  Network  Operations  Center  (NOC) 

ESI 

Naval  Sea  Systems  Command  (NAVSEA) 

PSP 

Warfrghter,  USN 

PSP 

1.  Administrative 

The  only  stakeholder  that  did  not  fall  into  one  of  the  three  basic  DS  elements  was 
NPS.  NPS  was  an  important  stakeholder  in  giriding  the  capstone  for  system  engineering 
and  subject  matter  expertise. 

2.  Platform  Service  Provider 

The  PSPs,  along  with  the  POI,  were  the  team’s  most  active  stakeholder. 

Noteworthy,  due  to  the  greater  nirmber  of  support  organizations  classified  as  a  PSP 

versirs  the  mrmber  of  organizations  classified  as  POI.  This  meant  that  the  team  was 
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dealing  with  a  complex,  multifaceted  PSP  that  was  distributed  by  function,  geographic 
location,  funding  lines,  and  responsibility. 

The  team  first  met  with  the  NSWC  PHD  -  Distance  Support  Advocacy  Office. 
The  office  provided  continual  project  guidance  as  well  as  existing  DS  documentation, 
studies,  and  technology  roadmaps.  NSWC  PHD  has  been  developing  DS  for  some  time, 
but  is  still  grappling  with  issues  such  as:  (1)  sensor  and  data  collection  mechanisms,  (2) 
ship  on-board  data  storage  and  processing  mechanisms,  (3)  prognostics  health 
management,  (4)  ship-to-shore  data  transfer  mechanisms,  (5)  shore-side  data 
warehousing,  (6)  mission-based  modeling  and  readiness  assessments,  and  (7)  ship  system 
product  life-cycle  analysis  (Naval  Surface  Warfare  Center,  Port  Hueneme  Division,  Air 
Dominance  Department  2013). 

NSWC  PHD  began  to  take  an  in  depth  technical  implementation  of  providing  DS 
beyond  email,  chat,  and  fly-away  teams  with  the  initiation  of  the  AEGIS  Wholeness 
program.  The  purpose  of  this  program  was  to  assist  AEGIS  ships  in  achieving  higher 
readiness  and  availability  metrics  (Naval  Surface  Warfare  Center,  Port  Hueneme 
Division,  Air  Dominance  Department  2013). 

While  this  program  helped  to  highlight  and  bring  attention  to  performance  issues 
through  in  depth  analysis,  it  became  apparent  that  the  effort  was  very  labor  intensive  and 
burdensome.  NSWC  PHD  -  Office  of  Engineering  and  Technology  began  to  accept 
proposals  to  automate  this  program  and  mature  the  technology  needed  to  provide  this 
capability. 
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AEGIS  Weapon  Systems 


Figure  48.  Distance  Support  Shipboard  Server  Concept  (from  Air  Dominance 

Department  2013,  9) 


Of  the  proposals  submitted,  the  DS  shipboard  server  (DS3)  concept  was  a  relevant 
model  to  emulate  with  subtle  changes.  The  DS3  concept,  as  shown  in  Figure  48,  is  of 
interest  due  to  its  unique  characteristic  of  being  located  outside  of  the  AEGIS  Weapon 
Systems  (AWS)  certification  boundary  (dotted  square  on  the  left-hand  side  of  the  figure). 
Part  of  the  issue  NSWC  PFID  has  with  trying  to  monitor  or  sensorize  the  AWS  is  that  any 
modification  to  the  AWS  requires  a  complete  combat  system  re-certification.  This  re¬ 
certification  is  very  time  consuming  and  costly.  With  the  DS3  being  located  outside  the 
AWS  boundary,  no  re-certification  is  needed  as  the  system  has  a  separate  accreditation 
boundary  around  itself.  This  is  also  particularly  useful  in  that  the  DS3  can  execute 
programs  that  are  not  certified  for  the  combat  system,  as  well  as  keep  them  updated  with 
patches  as  needed. 
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Mission  aiul  \\’aifaic.\rea“RealUncJis>  - 

Figure  49.  Future  Vision  of  Readiness  (from  Air  Dominance  Department  2013,  1 1) 

NSWC  PHD  has  future  visions  of  being  able  to  monitor  the  entire  ship  and 
transform  the  ship  into  an  expert  system.  Figure  49  gives  the  next  stage  of  monitoring  in 
terms  of  the  detect-to-engage  chain  to  create  readiness  models  based  on  mission 
capability.  This  will  tie  real-time  system  information  into  decision  making  for  warfare 
area  resource  assignments. 

In  reviewing  the  stakeholder  needs,  the  team  determined  that  the  PSPs  did  not 
need  a  shore  infrastructure  or  a  DS  center  but  rather  a  framework  and  designed-in  DS 
module  as  part  of  future  systems  to  help  better  facilitate  DS  from  the  PSPs.  Figure  50  was 
also  analyzed  to  ensure  all  NSWC  PHD  core  values  were  touched  upon  in  designing  a  DS 
solution. 
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Figure  50.  NSWC  PHD  Next  Generation  Readiness  (from  Naval  Surfaee  Warfare 

Center,  Port  Hueneme  Division  2003) 


3,  Enabling/Supporting  Infrastructure 

The  stakeholders  that  were  categorized  as  ESI  were  mainly  passive,  information 
sources  for  the  team.  This  was  due  to  the  nature  of  relationship  and  business  contract 
management  through  the  use  of  SLAs.  One  particular  stakeholder  was  kept  on  the  team’s 
watchlist  for  technical  risk.  This  was  the  Office  of  Naval  Research  (ONR).  ONR  in 
conjunction  with  Space  and  Naval  Warfare  System  Command  (SPAWAR)  are  in  the 
process  of  developing  a  capability  known  as  Naval  Tactical  Cloud  (NTC).  NTC’s 
purpose,  as  depicted  in  Figure  51,  is  to  improve  warfighting  effectiveness  while  operating 
inside  adversary  kill  chains.  This  was  an  important  development  to  watch  closely  as  the 
requirements  set  forth  by  the  NTC  could  have  had  an  impact  on  the  amount,  type,  or  even 
classification  of  data  being  transmitted. 
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Figure  5 1 .  Naval  “Data  Space”  (from  Office  of  Naval  Research  2014,  9) 


The  last  technical  risk  the  team  had  to  watch  ONR  for  was  the  potential  for  all 
data  to  change  from  existing  classification  domains,  as  shown  in  Figure  52,  to  a  single 
classified  domain.  This  was  unlikely  to  happen  in  the  near  future,  but  it  did  provide  a 
thought  provoking  design  consideration  when  analyzing  the  POI  and  what  to  monitor  and 
how  the  data  should  be  treated. 
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Figure  52.  Future  Security  Domains  (from  Porsche,  et  al.  2014,  21) 
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4. 


Platform  of  Interest 


The  POI  for  this  capstone  was  selected  to  be  the  HEL.  The  team  met  with 
stakeholders  from  PMS  405  -  Directed  Energy  and  Electric  Weapon  Systems  Program 
Office  to  gather  information  about  the  HEE  and  issues  concerning  support.  These  issues 
ranged  from  frequent  component  failure  to  environmental  degradation.  The  team  first 
took  on  the  approach  of  analyzing  the  HEE  currently  being  installed  on  the  EISS  PONCE 
(Office  of  Naval  Research  2014),  but  was  later  guided  by  NPS  advisors  to  take  a  more 
general  HEE  analysis  so  that  the  conclusions  would  not  be  centered  on  one  particular 
make  and  model.  The  information  about  the  make-up  of  the  HEE  was  provided  by  NPS, 
while  the  information  about  the  host  platform  was  provided  by  NSWC  PHD.  The  host 
platform  for  this  capstone  was  chosen  to  be  the  AEGIS  and  ECS  class  ships.  Information 
about  the  host  platforms  was  limited  to  the  “hotel  services”  provided  and  the  internal 
network  connectivity  of  the  platform. 

D,  CONCEPT  OF  OPERATIONS 

This  CONOPS  describes  the  POI  capabilities  required  to  allow  the  PSP  to 
accomplish  DS  as  determined  by  the  appropriate  SEAs  and  OLAs.  In  addition,  this 
CONOPS  will  explore  how  the  PSP  will  support  the  POI  to  provide  the  best  level  of 
service. 

•  Operating  Concept:  The  DSHEE  will  operate  within  AEGIS  and  ECS  class 
ships  while  maintaining  connection  to  the  complex  net-centric  architecture  of 
the  USN.  The  overall  POI  is  the  HEE.  The  HEE  is  a  guest  platform  being 
supported  on  the  host  platforms  AEGIS  and  ECS  class  ships.  Important  data  is 
collected  and  analyzed  from  the  HEE  via  the  DSHEE  module  and  then  routed 
through  ships  network  off  board  to  the  NOC.  Erom  the  NOC,  the  data  will  be 
routed  to  Navy  311  and  then  down  the  USN’s  multi-tiered  technical  support 
infrastructure  to  the  proper  PSP. 

•  Operating  Schedule:  The  DSHEE  will  be  able  to  operate  continuously  as 
needed  24  hours  a  day,  7  days  a  week.  This  operating  schedule  can  be 
autonomous  or  manually  controlled.  DSHEE  will  have  the  ability  to  suspend 
diagnostics  or  other  resource  impacting  functions  while  maintaining  HEE 
passive  sensor  recording.  The  amount  of  data  transmitted  from  DSHEE  to  the 
NOC  will  be  consistent  with  the  internal  data  storage.  This  function  can  also 
be  suspended  in  times  of  link  traffic  prioritization. 
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•  Mission  Support  Description:  The  overall  mission  support  of  the  DSHEL  will 
be  the  responsibility  of  the  HEL  or  the  ISEA  to  whieh  it  is  assigned.  As  the 
HEE  is  owned  by  PMS  405,  the  responsibility  will  fall  to  them  to  fund  the 
proper  ISEA  who  maintains  ownership  of  the  eombat  system  (NSWC  PHD). 
The  ESI  will  be  maintained  by  SPAWAR  who  will  provide  the  proper  SLA. 

•  Personnel:  All  individuals  eondueting  support  will  need  knowledge  of  the 
DSHEL.  The  DSHEL  will  not  be  servieed  or  maintained  by  ship’s  erew.  The 
ISEA  will  maintain  the  DSHEL  as  it  will  be  an  extension  of  the  HEL. 

•  Training:  DSHEL  training  will  be  aeeomplished  through  individual  On  the 
Job  Training  (OJT)  with  speeial  attention  given  to  sensorization,  network 
administration,  and  HEL  eharacteristies.  Shore  support  personnel  will  reeeive 
sustainment  training  and  data  analysis  training  that  is  foeused  programming, 
seripting,  and  modeling  and  simulation. 

•  Equipment:  The  DSHEL  equipment  will  be  designed  and  built  to  meet 
eommon  open  arehiteeture  standards  and  to  minimize  life-eyele  eosts.  The 
equipment  will  use  the  same  baseline  system  equipment  that  other  programs 
of  reeord  eurrently  proeure  to  keep  logistieal  footprints  small.  The  equipment 
will  have  maintenanee  eards  detailing  all  information  neeessary  to  provide 
support. 

•  Support:  Preventative  maintenanee  and  non-major  repairs  will  typieally  be 
eondueted  during  seheduled  maintenance  windows  in-port  or  underway. 
Critical  repairs  will  be  conducted  with  the  help  of  the  Integrated  Logistics 
Support  (ILS)  team.  Preventive  maintenance  will  be  limited  to  the  sensors  and 
other  functions  of  DSHEL  that  accrue  wear.  The  hardware  and  processing 
functions  of  DSHEL  will  follow  the  standard  ship  class  hardware  life-cycle 
replacement. 

•  Supply:  Onboard  sparing  will  be  limited  to  components  that  have  required 
preventative  maintenance.  DSHEL  hardware  and  processing  spares  will  be 
kept  shore  side  at  the  appropriate  PSP  provider  for  storage.  One  DSHEL  unit 
will  be  installed  for  use  at  the  land  based  test  site  for  directed  energy. 

•  Infrastructure:  Infrastructure  cost  will  not  include  the  PSP  or  the  ESI. 
Infrastructure  costs  for  the  DSHEL  will  be  limited  to  the  hardware,  software, 
processing,  and  data  collection  devices  used.  Hotel  services  from  the  host 
platform  will  be  required  to  operate  DSHEL. 

•  Information:  Information  concerning  the  DSHEL  will  be  documented 
electronically  and  stored  within  the  requirements  of  NSDSA.  Information 
generated  and  transmitted  by  DSHEL  will  undergo  analysis  and  archived  for 
long-term  storage.  This  data  will  be  used  for  trending  as  well  as  for  future 
support  endeavors  like  expert  system  creation  and  prognostics. 

•  Operating  Environment:  The  DSHEL  will  operate  in  the  standard  computing 
enclosure  as  dictated  by  the  host  platform  ship  class.  This  environment  should 
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mirror  that  of  an  enclosed  server  rack  with  proper  temperature,  power,  shock 
and  vibration  management.  The  data  collection  devices  on  DSHEL  will  vary 
greatly  depending  on  the  POI  and  the  stage  at  which  DSHEL  is  installed.  Eor 
future  systems,  data  collection  devices  will  be  integrated  and  selected  by  the 
design  team  with  PSP  input. 

•  Missions:  DSHEL  is  a  key  element  in  supporting  the  HEL  by  maintaining  a 
picture  of  the  HEL’s  health.  The  DSHEL  will  meet  this  challenge  through  the 
employment  of  multiple  data  collection  devices  at  key  interfaces,  critical 
components,  and  signals  of  interest.  DSHEL  will  verify  and  validate  that  all 
data  collected  is  correct  and  meaningful.  DSHEL  will  store  and  process  data 
for  action,  event  reconstruction,  transit,  trending,  and  other  future 
developments. 

•  Interoperability  with  Other  Elements:  DSHEL  will  operate  with  all  host 
platform  “hotel  services”  such  as  power,  water,  heating,  ventilation,  air 
conditioning  (HVAC),  and  network  connectivity.  The  ESI  and  the  POI  will 
agree  upon  specified  levels  of  service  through  the  use  of  SLAs.  Proper  OLAs 
will  be  authored  within  the  PSP  to  ensure  support  for  the  HEL  via  DSHEL  is 
complete.  If  DSHEL  is  installed  on  a  legacy  guest  platform,  DSHEL  will 
report  relevant  data  actions  to  the  user  as  specified  with  the  user  through  a 
SLA. 

•  Users  and  Other  Stakeholders:  The  core  users  of  DSHEL  will  be  the  PSP. 
Other  users  within  the  main  PSP  will  be  secondary  users  as  established  by 
various  OLAs.  If  DSHEL  is  installed  on  a  legacy  guest  platform,  DSHEL  will 
report  relevant  data  actions  to  the  user  as  specified  with  the  user  through  a 
SLA. 

•  Potential  Impacts:  DSHEL  has  the  potential  to  impact  network  traffic 
depending  on  the  degree  of  data  collection  and  visibility  required  by  the  PSP. 
Careful  attention  to  data  processing,  filtering,  and  compression  will  be  given 
to  ensure  that  this  does  not  become  an  issue.  Other  workarounds  include  large 
on-board  data  storage  and  dynamic  information  throttling  when  network 
resources  are  taxed. 

E,  DESIGN  REFERENCE  MISSION 

The  design  reference  mission  that  was  developed  for  the  DSHEL  system  is 
depicted  with  the  OV-1  diagram  for  DSHEL. 
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Figure  53.  DSHEL  OV-1  Diagram 


Figure  53  shows  the  types  of  DS  methods  that  the  DSHEL  system  will  support. 
Additionally,  it  shows  the  platforms  the  DSHEL  system  will  be  implemented  on,  as  well 
as  the  shore-based  facilities  where  the  information  will  be  used  by  Elect  support 
personnel. 

The  DSHEL  system  will  not  be  operated  or  maintained  by  the  sailor  in  any  way. 
Information  shall  be  collected  in  a  passive  and  active  manner  by  the  shore-based  support 
sites  (ISEA,  RMC,  and  Navy  311)  and  used  to  provide  support  for  the  HEL  weapons 
system.  The  information  will  be  disseminated  in  accordance  with  the  Joint  Elect  Eorces 
Maintenance  Manual  (JEEM).  Specifically,  when  the  ship  has  an  issue  with  the  HEL 
system,  the  sailors  will  submit  a  ticket  with  Navy  311.  The  ticket  will  then  be  routed  to 
the  Regional  Maintenance  Center  (RMC)  for  assistance.  The  RMC  will  have  the  ability  to 
gather  diagnostic  information  from  DSHEL  to  provide  direction  on  parts  that  may  have 
failed  or  further  troubleshooting  that  may  need  to  take  place.  If  the  RMC  is  unable  to 
resolve  the  ticket  within  90  days  of  submission  (Navy  2013),  the  ticket  will  be  forwarded 
to  the  ISEA  for  resolution.  The  ISEA  will  have  privileged  capability  with  the  DSHEL 
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system,  allowing  remote  conneetivity  to  the  system.  Privileged  capabilities  refer  to  an 
extended  and  enhanced  set  of  functions  for  the  ISEA  which  aren’t  typically  available  to 
the  RMC  support  staff.  When  parts  fail,  the  DSHEL  system  will  immediately  report  the 
information  back  to  shore  in  advance  of  any  ticket  being  generated  by  the  crew.  This  will 
allow  the  shore  support  infrastructure  to  take  a  more  proactive  role  in  the  support  of  the 
HEE  system. 

F.  SUMMARY 

Erom  the  stakeholder  analysis  and  literature  review,  it  was  determined  that  the 
focus  of  the  capstone  should  be  on  the  creation  of  a  DS  framework  and  its  application  to 
the  HEE.  The  DS  framework  in  this  chapter  was  kept  high  level  and  generic  due  to  the 
overall  concept  of  the  framework  being  flexible  and  modular  enough  to  fit  within  the 
rigid  organizational  structure  of  the  USN.  Chapter  III  shows  how  the  DS  framework  was 
applied  to  the  USN’s  current  organizational  structure  as  well  as  the  POI,  HEE.  The 
analysis  of  the  HEE  was  also  kept  at  a  high  level  to  ensure  that  it  would  be  applicable  to 
future  HEEs. 
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III.  REQUIREMENTS  ANALYSIS 


In  this  chapter,  the  DS  framework  is  applied  to  the  USN’s  organizational  structure 
and  to  the  POI,  the  HEL.  From  this  application  and  subsequent  breakdown,  requirement 
areas  were  identified  and  noted  as  operational,  functional,  and  performance.  While  the 
team  cannot  generate  requirements  that  a  platform  service  provider  (PSP), 
enabling/supporting  infrastructure  (ESI),  and  platform  of  interest  (POI)  must  adhere  to, 
these  specific  areas  should  be  serutinized  for  requirements  as  they  have  a  great  effeet  on 
DS. 

A,  PRIME  DIRECTIVE 

Any  system  that  is  composed  of  multiple  parts  will  have  parts  that  wear  out,  or 
require  speeial  conditions  to  work  properly.  There  are  no  perpetual  motion  maehines  or 
perfect  systems  which  never  degrade.  As  a  result,  it  is  neeessary  to  be  able  to  support 
these  systems  by  a  combination  of  anticipating  and  addressing  their  needs.  This 
multifaeeted  type  of  maintenance  is  called  DS.  DS  allows  for  information  about  a  system 
to  be  analyzed  and  issues  corrected  without  having  engineers  or  technicians  on-site  with 
the  system.  DS  has  three  main  phases.  First  would  be  obtaining  the  necessary 
information,  second  the  analysis  of  this  information,  and  finally  reacting  to  the  analysis. 
DS  incorporates  all  three  of  these  phases  in  order  to  monitor  and  address  issues  within  a 
system  without  being  physically  present  on  the  examined  system.  DSHEE’s  goal  is  to 
provide  seeure,  remote  maintenanee  and  support  services  to  the  HEE  system  when 
fielded  by  the  USN. 

B,  SYSTEM  DEFINITION 

In  this  seetion,  eaeh  element  of  the  DS  framework  in  reference  to  the  DSHEE 
Applieation  Context  Diagram  (Figure  54)  was  assigned  to  the  proper  USN  organization 
and  the  subsequent  POI.  This  capstone’s  foeus  was  the  POI  and  thus,  the  PSP,  ESI,  and 
the  agreements  between  them  (SLAs  and  OEAs)  were  not  detailed. 
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Figure  54.  DSFIEL  Application  Context  Diagram 


1,  Platform  Service  Provider 

The  PSP  for  the  USN  is  highly  dependent  on  the  POL  Different  support 
organizations  are  in  charge  of  different  platforms  based  on  platform  capability  and  type 
of  support  needed.  This  section  will  focus  on  the  USN  support  organizations  that  provide 
expertise  to  combat  system  elements  and  weapons  installed  on  AEGIS  and  ECS  surface 
combatants. 

Eigure  55  illustrates  the  typical  flow  of  information  from  the  POI  to  the  PSP 
within  the  USN.  In  this  setup,  any  ESI  involvement  is  not  visible  to  the  parties  and 
appears  to  be  seamless.  When  an  issue  arises  from  a  system  (POI)  on  the  ship,  the  sailor 
takes  action  to  remedy  the  issue.  Due  to  this  action,  the  sailor  is  often  considered  a  Tier  1 
technical  support  member.  This  means  the  sailor  has  not  only  an  OEA  with  the  ship  but 
also  an  SLA  with  the  POI.  SLAs  and  OLAs  on  board  a  ship  are  different.  A  SLA  is  an 
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action  the  sailor  completes  to  keep  the  POI  operational  (exeeution  of  a  maintenance 
requirement  eard  (MRC)).  An  OLA  on  board  a  ship  for  a  sailor  may  be  an  action,  such  as 
performing  assigned  duties  or  operating  system  equipment.  The  SLA  dividing  the  sailor 
from  the  Help  Desk  represents  the  SLA  between  the  POI  and  PSP.  The  POI  is  owned  by 
an  organization  different  from  the  organization  providing  the  support  serviees.  Many 
SLAs  and  OLAs  are  not  shown  within  the  graphic  in  order  to  simplify  the  proeess. 

If  a  sailor,  also  considered  Tier  1  teehnieal  support,  eannot  remedy  the  issue  on 
the  POI,  he  eontaets  the  USN  Help  Desk,  also  known  as  Navy  311.  Different  programs 
and  platform  have  distinet  ways  in  which  they  eontaet  shore  support.  For  AEGIS 
systems,  the  sailor  eontaets  Navy  311  direetly  to  initiate  support.  For  LCS  systems,  the 
sailor  uses  a  system  ealled  maintenanee  figure  of  merit  (MFOM)  automated  work 
notification  (AWN)  to  initiate  support  and  then  contacts  Navy  3 1 1  to  file  a  serviee  tieket 
for  reeord  keeping  purposes.  Once  these  systems  have  been  contaeted  and  the  support 
request  initiated,  they  begin  their  travel  through  the  multi-tiered  teehnieal  support  group 
as  defined  by  the  Joint  Fleet  Maintenance  Manual  (JFFM)  and  private  industry  support 
organizations  managed  with  OFAs  and  SFAs.  Tier  2  teehnieal  support  is  managed  by  the 
regional  maintenanee  eenters  (RMC).  They  are  a  doek-side  organization  that  ean  handle 
most  teehnieal  issues  not  involving  combat  system  speeifie  hardware  and  software. 
RMCs  also  provide  standardized  maintenance  and  modernizations  to  ship  systems.  These 
inelude  the  Southwest  RMC,  Southeast  RMC,  Puget  Sound  Naval  Shipyard  and 
Intermediate  Maintenance  Facility,  Norfolk  Ship  Support  Activity,  U.S.  Naval  Ship 
Repair  Faeility  and  Japan  RMC,  Pearl  Harbor  Naval  Shipyard  and  Intermediate 
Maintenanee  Facility,  as  well  as  the  Commander,  USN  RMC. 

If  the  RMC  is  unable  to  resolve  the  issue,  it  is  routed  to  the  appropriate  Tier  3  in- 
service  engineering  agent  (ISEA).  The  ISEA  is  responsible  for  support  on  systems 
installed  on  the  ship.  Their  functions  include  installation,  certifieation,  training  and 
qualification  of  system  users,  logistieal  support,  and  test  and  evaluation.  Most  issues  are 
solved  at  this  level  of  teehnieal  support. 
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Figure  55.  USN  Platform  Service  Provider  Flow  (Icons  from  Flaticon  2014) 


The  last  and  final  support  tier,  Tier  4,  is  the  original  equipment  manufacturer 
(OEM).  The  OEM  will  vary  from  system  to  system  based  on  the  particular  design  agent. 
This  level  of  technical  support  is  reserved  for  issues  that  are  the  most  complex  and 
typically  require  design  changes/solutions  to  the  hardware  or  software. 

2,  Enabling/Supporting  Infrastructure 

The  ESI  for  the  USN  in  terms  of  tactical  communication  is  an  organization  named 
Space  and  Naval  Warfare  Systems  Command  (SPAWAR).  SPAWAR  is  the  technical 
authority  and  acquisition  command  for  Command,  Control,  Communications,  Computers, 
Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR)  systems.  They  also  develop, 
deliver,  and  sustain  communication  and  information  capabilities  for  the  Elect.  Eigure  56 
shows  how  SPAWAR  interacts  as  the  ESI. 
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Figure  56.  USN  Enabling/Supporting  Infrastructure  Flow  (Icons  from  Flaticon  2014) 

All  communications  between  the  ship  and  the  shore  must  go  through  SPAWAR. 
When  the  sailor  contacts  the  PSP  for  support,  a  communication  circuit  must  be 
established  with  a  satellite  link  using  the  SHF  band.  AEGIS  and  ECS  ships  both  use  this 
link  structure.  The  inbound  communication  link  from  the  ship  is  received  by  a  satellite 
antenna  shore  center  which  routes  the  information  to  the  nearest  NOC.  Due  to  the  USN’s 
global  presence,  NOCs  are  established  all  over  the  world.  Erom  the  NOC,  the  support 
request  is  routed  through  SPAWAR’s  WAN/EAN  to  the  appropriate  network  boundary 
firewall  to  be  forwarded  to  the  shore  support  installation. 

3,  Platform  of  Interest 

With  the  installation  of  the  solid  state  laser  -  quick  reaction  capability  (SSL-QRC) 
AN/SEQ-3  (XN-1)  Easer  Weapon  Systems  (EaWS)  on  the  USS  PONCE,  it  is  apparent 
that  the  POI  is  a  guest  platform  contained  within  a  host  platform.  This  capstone  used  a 
more  generic  approach  in  analyzing  the  HEL;  the  host  platform  analysis  was  done  from 
the  standpoint  of  AEGIS  and  ECS  surface  combatants.  Due  to  weapon  systems  being 
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installed  on  ships,  this  inherently  makes  those  weapons  systems  eategorieally  guest 
platforms  eontained  within  host  platforms. 

a.  Host  Platform 

The  host  platform  plays  an  import  role  in  providing  for  the  POL  As  illustrated  in 
Figure  57,  for  HEL,  the  host  platform  would  be  in  eharge  of: 

•  Hotel  serviees 

o  Ship  form  faetor  spaee 

■  Above  deck — Provide  location  and  space  for  the  HEL  and  its  required 
infrastructure  such  as  an  enclosure. 

■  Below  deck — Provide  location  and  space  for  the  HEL  system  sub¬ 
components.  The  HEL  system  sub-components  will  most  likely  be 
distributed  throughout  the  ship  to  meet  survivability  requirements. 

o  Conditioned  power — Provide  stable  and  clean  power  from  the  ship  at  the 
proper  utility  frequency  and  phase. 

o  Chilled  water — Provide  cooled  water  from  the  ship’s  plant.  This  water  can 
be  chilled  seawater,  fresh  water,  or  deionized  water  and  has  variable  flow 
rates. 

o  Electronic  dry  air — Provide  air  conditioning  for  specific  humidity  levels  to 
cool  electronic  devices  without  harm. 

•  Support  services 

o  HM&E  support — Provide  technician  level  support  for  all  components  of 
the  HEL  system  that  fall  into  mechanic  level  maintenance  such  as 
hydraulic  lines,  pumps,  voids,  and  tanks. 

o  Tier  1  technical  support — Provide  sailor  support  in  the  form  of  Planned 
Maintenance  Systems  (PMS)  and  execution  of  MRCs. 

o  Meteorological  and  oceanographic  (METOC)  data — Provide  information 
describing,  characterizing,  and  detailing  the  current  environment  external 
to  the  ship. 

•  Command  and  control  systems 

o  Detect  to  engage  (DTE)  kill  chain  command — Provide  kill  chain  actions 
and  events  that  take  place  when  an  engagement  is  deemed  necessary.  The 
DTE  kill  chain  is  made  up  of  the  following  steps: 

■  Detect — Responsible  for  the  planning,  detection,  entry,  tracking,  and 
identification  of  targets. 
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■  Control — Responsible  for  the  threat  evaluation  and  weapons  pairing 
step  for  the  combat  system  including  fine/rough  course  track,  gimbal 
pointing,  and  sensor  detection. 

■  Engage — Responsible  for  the  engagement  and  engagement  evaluation 
of  the  target. 

o  Network  communications — Provide  network  backbone  within  the  ship 
that  allows  all  communication  between  system,  operators,  and  command 
centers 

o  Display  systems — Provide  control  and  maintenance  displays  of  the  HEL 
will  be  located  throughout  the  ship. 

o  Operator  control  console — Provide  physical  HEL  weapon  console  will  be 
located  with  the  ships  combat  information  center  (CIC).  This  console  can 
be  unique  to  the  particular  system  or  can  be  a  service  that  any  console  can 
operate  as  in  the  defined  sub  mode. 


The  host  platform  will  be  analyzed  in  a  later  section  for  important  data  needed  to 
construct  the  minimum  data  picture  threshold  in  order  to  perform  DS  on  the  HEL. 
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b.  Guest  Platform 


The  guest  platform  and  POI  is  the  HEL.  An  in  depth  analysis  of  the  SSL-QRC 
AN/SEQ-3  (XN-1)  EaWS  on  the  EISS  PONCE  would  be  limited  to  the  program  itself, 
thus  the  HEE  under  analysis  will  be  a  generie  version  (SSE  and  EEE)  so  that  the  results 
from  this  eapstone  can  be  applied  to  future  HEE  designs. 
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Eigure  58.  Basic  Easer  Cross  Section  (from  Harney  2013,  85) 


Eigure  58  shows  a  simple  schematic  diagram  of  a  simple  laser  model.  The  basics 
of  laser  operation  involve  the  following  components:  an  energy  source  (also  known  as  a 
“pump”),  laser  medium  (also  known  as  a  gain  medium),  and  two  reflectors  (also  known 
as  the  laser  cavity/optical  resonator).  There  are  many  types  of  lasers  available,  these 
include:  gas  lasers,  chemical  lasers,  dye  lasers,  metal-vapor  lasers,  solid-state  lasers, 
semiconductor  lasers,  free  electron  lasers,  gas  dynamic  lasers.  Samarium  lasers,  Raman 
lasers,  and  nuclear  pumped  lasers. 

The  team  determined  that  of  the  lasers  available,  the  solid  state  and  free  electron 
lasers  would  be  analyzed  as  they  proved  to  be  the  most  viable  options  for  installation  and 
fielding  due  to  current  USN  requirements.  The  basic  elements  for  all  lasers  and  similar 
with  the  exceptions  coming  from  laser  excitation  mechanism  (pumping)  used  to  generate 
population  inversion  inside  the  laser  medium  and  the  laser  medium  itself. 
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Most  SSL  implement  three  eommon  forms  of  optieal  pumping  to  aehieve  a 
population  inversion.  These  three  eommon  optieal  pumping  methods  are  known  as 
flashlamps,  diode  lasers,  and  other  lasers  (Harney  2012).  Figure  59  gives  some  possible 
advantages  and  disadvantages  in  SSL  pumping  mechanisms  and  shows  the  geometries 
used  in  pumping  the  laser  rod. 
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Figure  59. 


Diode  Laser  Pumping 

•  Efficient  -  reduced  power  consumption 

•  Significantly  reduced  cooling  recjuirements 

•  Cooling  may  still  be  required  for  repetitive  pulse  operation 

•  Reduced  stress  birefringence  (potentially  negligible) 

•  Improved  reliability' 

•  Expensive 
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Diode  Laser  Pumping  Characteristics  and  Geometries  (from  Harney  2012) 


Figure  60  gives  some  possible  advantages  and  disadvantages  in  flashlamp 
pumping  mechanisms  and  shows  the  geometries  used  in  pumping  the  laser  rod. 
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Flashlamp  Primping 

•  Relati\'ely  inefEicient  -  high  power 
consumption 

•  Significantly  waste  heat  to  eliminate 

•  Will  probably  require  cooling  for 
repetitive  pulse  operation 

•  Thermally-induced  stress  birefhngence 
must  be  compensated 

•  Inexpensive 


Comparison  of  pumo  cavity  geometries 

•  Circular  -  Inexpensive,  Poor  pump 
uniformity 

•  Elliptical  -  Expensive,  Fair  pump 
uniformity 

•  Double  Elliptical  -  More  expensive, 
Better  pump  uniformity 

•  Quad  Elliptical  -  Very  expensh'e,  Good 
pump  uniformity 

•  Hohlraum  -  Inexpensi\'e,  Good  pump 
uniformity 
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Figure  60.  Flashlamp  Pumping  Characteristics  and  Geometries  (after  Harney  2012) 


Free  electron  lasers  (FELs)  use  considerably  more  power  and  have  a  much  larger 
infrastructure  footprint  due  to  how  they  produce  stimulated  emission.  Instead  of  pumping 
a  medium  to  produce  stimulated  emission,  FELs  use  a  relativistic  beam  from  a  particle 
accelerator  to  “fire”  electrons  through  a  series  of  strong  magnetic  fields  which  alternate 
directions  causing  the  electrons  to  emit  radiation  (Harney  2012).  The  emitted  radiation 
then  propagates  in  the  lasing  cavity  until  it  exits.  Eigure  61  shows  a  schematic  diagram  of 
a  EEL.  The  EEL  is  still  in  its  development  stages  and  suffers  from  extremely  complex 
hardware  as  well  as  radiation  issues. 
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Figure  61 .  Free  Electron  Laser  Diagram  (from  Harney  2012,  216) 


The  HEL  system  itself  has  many  internal  systems  that  need  to  be  analyzed.  These 
systems  include,  but  are  not  limited  to: 

•  Laser 

o  Energy  source — power  generation  and  storage  for  the  HEL  system 

o  Laser  cavity  and  gain  medium — cavity  where  the  gain  medium  is  pumped 
to  reach  proper  population  inversion  levels 

o  Diode  pump — pumps  the  laser  rod  (gain  material) 

o  Phase  adjuster  and  control  electronics — beam  and  phase  control 
equipment  for  the  pump  diodes/fibers 

o  Master  oscillator,  power  amplifier  (MOPA) — scalable  approach  to 
achieving  higher  power  with  the  combination  of  lower  power  lasers; 
master  oscillator  seeds  other  laser  amplifiers 

o  Thermal  management  systems — cooling  equipment  for  excess  waste  heat 
created  by  the  HEL 

o  Safety  systems — fire,  personnel,  operation,  and  system  interlocks  to  meet 
safety  requirements 

o  Control  systems — systems  needed  to  control  the  HEL  in  terms  of 
mechanics,  operation,  communication,  health,  predictive  avoidance,  and 
maintenance 

o  Magnetic  array  (EEL  only) — large  magnets  used  to  oscillate  the  electron 
beam. 

o  Particle  accelerator  (PEL  only) — relativistic  beam  used  to  accelerate 
electrons 


119 


o  Electron  beam  transport  (FEE  only)  — strong  magnets  used  to  direct  the 
electron  beam  to  and  from  the  magnetic  array 

•  Beam  control 

o  Wavefront  sensors — sensors  that  sample  beam  quality  to  ensure  operation 
at  expected  levels 

o  Reflectors 

■  Deformable — adjustable  surfaces  to  shape  and  direct  beam  as  desired 

■  Segmented — series  of  mirrors  used  to  combine  smaller  beams  into  one 

■  Fast  Steering — high  performance  two  dimensional  directing  mirror 

■  Corner  Cube — three  mirror  or  prism  used  to  redirect  the  beam 

■  Piezoelectric — high  speed,  solid  state  mirror 

■  Primary,  secondary,  tertiary  -  reflectors  located  in  the  telescope 
o  Optics 

■  Collimating  lenses — optic  used  to  narrow  out  beams. 

■  Diffractive  or  spectral  combiner — optics  used  to  combine  beams. 

■  Adaptive — optics  used  to  improve  performance  by  reducing  wavefront 
distortion  at  the  point  of  interest 

o  Beam  window — glass  cover  that  protects  the  HEE  from  the  outside 
elements 

•  Atmospheric,  tracking,  and  pointing  (ATP) 

o  Illuminator — system  used  to  highlight  target  before  engaging 

o  Fine  and  coarse  tracker — tracking  system  used  to  track  target  object  in 
differing  wavelengths  depending  on  operation  mode 

o  Gimbal  and  stabilization — equipment  used  to  point  the  HEE  in  different 
directions  and  stabilize  optics  for  use 

o  Enclosure — above  deck  cover  for  equipment 

Figure  62  shows  the  basic  elements  of  a  HEE.  The  basic  elements  of  any  HEE  can 
be  categorized  into  one  of  the  three  following  groups:  laser,  beam  control,  or  ATP.  Figure 
63  shows  the  breakdown  of  a  potential  SSE  laser  element.  Figure  64  is  the  breakdown  as 
applied  to  a  FEE.  While  the  internal  architecture  may  change,  the  basic  principles  are  the 
same. 
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Figure  62.  HEL  Basic  Elements 
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Eigure  63.  HEE  -  SSE  Easer  Element  Interactions  and  Makeup 
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Host  Platform 


HEL  -  EEL  Laser  Element 


Figure  64.  FIEL  -  FEL  Easer  Element  Interactions  and  Makeup 


Eigure  65.  HEL  Beam  Control  Element  Interactions  and  Makeup 
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The  beam  control  configurations,  as  illustrated  in  Figure  65  and  Figure  66,  can 
also  vary  due  to  requirements,  space  form  factor,  capability,  and  environment.  In  general, 
the  beam  control  elements  look  to  maintain  beam  stability  and  quality. 


Figure  66.  HEL  ATP  Element  Interactions  and  Makeup 


Similar  to  the  beam  control  element,  the  ATP  element  also  varies  from 
requirements,  space  form  factor,  capability,  and  environment.  There  are  many  different 
telescope  configurations. 

4,  DSX  to  DSHEL 

In  following  the  DS  framework,  the  DSX  configuration  chosen  was  the 
Distributed  -  Multipoint,  All  Inclusive.  This  configuration  was  chosen  due  to  the  multiple 
data  sources  that  need  to  be  sensorized  from  the  host  platform.  This  configuration  was 
also  chosen  due  to  surface  combatant  requirements  to  have  the  HEL  system  distributed 
throughout  the  ship  to  meet  survivability  requirements. 

The  sensor  collection  network  configuration  chosen,  as  indicated  in  Eigure  67, 
will  be  a  combination  of  a  star  and  mesh  topology.  The  star  methodology  will  be  used 
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with  major  HEL  system  elements  as  well  as  hardware  cabinets.  This  will  allow  two  main 
nodes  (for  redundancy)  with  each  local  network  to  report  out  the  sensor  status  of  the 
internal  nodes  to  the  main  DSHEL  controller.  The  mesh  topology  will  govern  the  star 
main  nodes.  This  allows  a  fault  tolerant  network  to  be  created  when  sharing  control 
information  and  status  requests  from  the  DSHEL  controller. 
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Eigure  67.  DSHEL  Sensor  Collection  Network 


The  sensor  collection  network  will  monitor  and  report  the  following  parameters  as 
categorized  by  host  platform  and  POI; 

•  Hotel  services 

o  Ship  form  factor  space 

■  Above  deck — temperature,  pressure,  wind  speed,  wind  direction, 
humidity,  precipitation  rate,  visibility,  cloud  height,  shock,  vibration, 
and  cloud  coverage 

■  Below  deck — Temperature  and  humidity 
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o  Conditioned  power — Voltage,  eurrent,  phase,  surge,  and  ground  signal 
o  Chilled  water — flow  rate,  temperature,  purity,  and  pH  level 
o  Eleetronie  dry  air — temperature,  humidity,  and  flow  rate 
Support  serviees 

o  HM&E  support — hydraulie  pressure 

o  Tier  1  teehnieal  support — maintenanee  aetions  and  events 

o  Meteorologieal  and  oeeanographie  (METOC)  data  -  see  hotel  serviees  - 
above  deek,  sea  state,  and  ship  motion. 

Command  and  eontrol  systems 

o  Deteet  to  engage  (DTE)  kill  ehain  eommand  -  eonneetivity  with  DTE  and 
eommands  sent 

o  Network  eommunieations  -  link  utilization,  hop  eount,  speed,  paeket  loss, 
lateney,  path  reliability,  path  bandwidth,  throughput,  load,  and  maximum 
transmission  unit 

o  Display  systems — signals  sent  and  reeeived 

o  Operator  eontrol  eonsole — signals  sent  and  reeeived 

Easer,  beam  eontrol,  and  atmospherie,  traeking,  and  pointing  (ATP) 

o  Total  intensity  over  time  (Harney  2012,  401) 

o  Total  energy  in  pulse  (Harney  2012,  401) 

o  Speetral  eontent  (Harney  2012,  401) 

o  Degree  of  polarization  (Harney  2012,  401) 

o  Angular  divergenee  (Harney  2012,401) 

o  Intensity  profile  (Harney  2012,  401) 

o  Shoek  and  vibration 

o  Temperature  (op ties,  mirrors) 

o  Hardware  utilization 

o  Software  exeeution  (running  on  hardware) 

o  Usage  modes  and  assoeiated  time 

o  Aperture  radius 

o  Cavity  loss  eoeffieient 

o  Magnetic  field  (EEE  only) 

o  Beam  quality 

o  Wavelength,  phase 


o 

Greenwood  frequency 

o 

Gain 

o 

Decay  rate 

o 

Irradiance 

o 

Wiggler  vector  potential  (EEE  only) 

o 

Cavity  length 

o 

Wiggler  period  (EEE  only) 

o 

Number  of  wiggler  periods  (EEE  only) 

o 

Isoplanatic  angle  (if  available) 

o 

Eried  coherence  length 

o 

Object  distance 

o 

Dwell  time 

o 

Easer  spot  size 

While 

many  of  the  items  listed  above  cannot  be 

because  they 

are  inherent  characteristics  of  the  system. 

important  in  determining  behavior  profiles  of  the  HEL. 


measured  via  sensorization 
the  parameters  above  are 


C.  REQUIREMENTS  SYNOPSIS 

Requirements  were  elicited  from  multiple  viewpoints,  topic  areas,  and 
stakeholders.  These  were  key  for  the  documentation  of  physical  and  functional  needs  of 
the  DSHEL  product,  processes,  and  services.  The  DSHEE  structure  and  characteristics  of 
the  requirements  generated  are  laid  out  below. 

1.  Structure 

The  language  of  requirements  can  be  very  confusing,  especially  when  terms  like 
“shall,”  “will,”  and  “must”  all  have  similar  meanings.  To  avoid  confusion,  requirements 
for  DSHEE  followed  the  structured  language  format  below: 

•  “Shall,”  the  emphatic  form  of  the  verb,  shall  is  used  throughout  sections  the 
specification  whenever  a  requirement  is  intended  to  express  a  provision  that  is 
binding  (Department  of  Defense  2014,  1 1). 
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•  “Will”  is  used  to  express  a  deelaration  of  purpose  on  the  part  of  the 
Government.  “Will”  is  also  used  in  eases  where  simple  futurity  is  required 
(Department  of  Defense  2014,  11). 

•  “Should”  is  used  to  express  non-mandatory  provisions  (Department  of 
Defense  2014,  11). 

•  “May”  is  used  to  express  non-mandatory  provisions  (Department  of  Defense 
2014,  11). 

•  “Must”  is  used  to  express  mandatory  provisions.  “Shall”  is  used  instead 
(Department  of  Defense  2014,  11). 

•  Indefinite  terms,  sueh  as  “and/or,”  “suitable,”  “adequate,”  “first  rate,”  “best 
possible,”  “and  others,”  and  “the  like”  are  not  used.  The  use  of  “e.g.,”  “ete.,” 
and  “i.e.,”  are  avoided  (Department  of  Defense  2014,  12). 

•  Ambiguous  Adverbs  and  Adjectives,  such  as  “almost  always,”  “significant,” 
“minimal,”  “timely,”  “real-time,”  “precisely,”  “appropriately,” 
“approximately,”  “various,”  “multiple,”  “many,” 

•  “Few,”  “limited,”  and  “accordingly”  are  avoided  (International  Council  On 
Systems  Engineering  2010,  79). 

•  Open-Ended,  Non-Verifiable  Terms,  such  as  “provide  support,”  “but  not 
limited  to,”  and  “as  a  minimum”  are  avoided  (International  Council  On 
Systems  Engineering  2010,  79). 

•  Comparative  Phrases,  such  as  “better  than”  and  “higher  quality”  are  avoided 
(International  Council  On  Systems  Engineering  2010,  79). 

•  Eoopholes,  such  as  “if  possible,”  “as  appropriate,”  and  “as  applicable”  are 
avoided  (International  Council  On  Systems  Engineering  2010,  79). 

•  Other  Indefinites,  such  as  “etc.,”  “and  so  on,”  “to  be  determined  (TBD),”  “to 
be  reviewed  (TBR),”  and  “to  be  supplied  (TBS).”  are  avoided  (International 
Council  On  Systems  Engineering  2010,  79). 

2.  Characteristics 

Requirement  characteristics  of  DSHEE  had  the  following: 

•  Necessary — Authoring  or  levying  additional  requirements  that  add  no 
capability  or  performance  to  the  system  are  of  no  value.  Additional  “useless” 
requirements  come  in  two  varieties:  (1)  unnecessary  specification  of  design, 
which  should  be  left  to  the  discretion  of  the  designer,  and  (2)  a  redundant 
requirement  covered  in  some  other  combination  of  requirements  (International 
Council  On  Systems  Engineering  2010,  76). 
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•  Implementation  Independent — Requirements  were  ereated  and  applied  by 
dietating  what  was  to  be  performed  by  the  system,  not  how  the  system  was  to 
perform  the  task  (International  Council  On  Systems  Engineering  2010,  76). 

•  Clear  and  Concise — Requirements  were  exact,  used  clear  language,  and 
detailed  enough  to  rule  out  any  and  all  other  interpretations  (International 
Council  On  Systems  Engineering  2010,  76). 

•  Complete — Requirements  stood  on  their  own,  measurable  and  not  in  need  of 
further  investigation  to  provide  capabilities  and  characteristics  (International 
Council  On  Systems  Engineering  2010,  76). 

•  Consistent — Requirements  were  not  in  disagreement  with  each  other. 
Adhesion  to  similar/like  standards,  units,  conversion  values,  interfaces,  and 
specifications  was  best  ((International  Council  On  Systems  Engineering  2010, 
77). 

•  Achievable — Requirements  had  the  ability  of  being  attained  and  securable. 
Requirement  achievability  is  directly  related  to  the  ability  to  measure  and  rate 
the  effectiveness  of  data  collected  about  a  particular  requirement 
(International  Council  On  Systems  Engineering  2010,  77). 

•  Traceable — Requirements  flowed  from  higher  level  specifications  down  to 
lower  levels.  Complex,  non-obvious  requirements  were  made  up  of  multiple, 
lower  level,  simple  requirements  (International  Council  On  Systems 
Engineering  2010,  77). 

•  Verifiable — Requirements  were  verified  and  validated  by  at  least  one  of  the 
following  methods:  inspection,  analysis,  demonstration,  or  test  (International 
Council  On  Systems  Engineering  2010,  77). 

3.  Sources 

DSHEE  requirement  sources  came  from  all  environments  and  user  interaction 
levels.  The  requirements  were  generated  from  customers,  end  users,  organizations, 
support  structures,  environmental  factors,  geographic  locations,  policies,  laws,  and 
regulations.  Below  are  the  chosen  pre-existing  frameworks  and  methodologies  that  were 
analyzed  for  requirement  generation. 

a.  International  Council  on  System  Engineering 

The  International  Council  on  System  Engineering  (INCOSE)  framework,  Eigure 
68,  offered  DSHEE  detailed  insight  into  the  impact  on  requirements  generation  by 
external,  organizational,  and  project  environments. 
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External  Environment 


LAWS  &  REGULATIONS  •  LEGAL  LIABILITIES  •  SOCIAL  RESPONSIBILITIES  •  TECHNOLOGY  BASE 
•  LABOR  POOL  •  COMPETING  PRODUCTS  •  STANDARDS  &  SPECIFICATIONS  •  PUBLIC  CULTURE 


Organization’s  Environment 


•  POLICIES  &  PROCEDURES  •  STANDARDS  &  SPECIFICATIONS  •  GUIDELINES 
•  DOMAIN  TECHNOLOGIES  •  LOCAL  CULTURE 


Project  Environment 


■  DIRECTIVES  &  PROCEDURES  •  PLANS  •  TOOLS 
•  PROJECT  REVIEWS  •  METRICS 


Project  Support 


Project  Management 
Agreement  Support 


Project  A 


Process  Groups  for 
Engineering  Systems 


Acquisition  &  Supply 
Technical  Management 
System  Design 
Product  Reaiization 
Technical  Evaluation 


Project  B 


Project  C 


r 


Organizational  Support 


Investment  Decisions 
External  Agreements 
Infrastructure  Support 
Resource  Management 
Process  Management 
Production 
Field  Support 


Figure  68.  INCOSE  Requirements  Elieitation  Areas  (from  INCOSE  2012,  75) 


b.  DOTMLPF-P 

DOTMLPE-P  is  a  solution  spaee  framework  used  by  the  DOD  that  pertains  to  the 
eight  possible  non-materiel  elements  involved  in  solving  warfighting  eapability  gaps 
(Defense  Aequisition  University  2014).  The  eight  non-materiel  elements  are  as  follows: 

•  Doetrine:  the  way  we  fight  (e.g.,  emphasizing  maneuver  warfare,  combined 
air-ground  campaigns). 

•  Organization:  how  we  organize  to  fight  (e.g.,  divisions,  air  wings,  Marine-Air 
Ground  Task  Forces). 

•  Training:  how  we  prepare  to  fight  tactically  (basic  training  to  advanced 
individual  training,  unit  training,  joint  exercises,  etc). 

•  Material:  all  the  “stuff’  necessary  to  equip  our  forces  that  DOES  NOT  require 
a  new  development  effort  (weapons,  spares,  test  sets,  etc  that  are  “off  the 
shelf’  both  commercially  and  within  the  government). 

•  Leadership  and  education:  how  we  prepare  our  leaders  to  lead  the  fight  (squad 
leader  to  4-star  general/admiral  -  professional  development). 

•  Personnel:  availability  of  qualified  people  for  peacetime,  wartime,  and  various 
contingency  operations. 

•  Facilities:  real  property,  installations,  and  industrial  facilities  (e.g., 
government  owned  ammunition  production  facilities). 
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•  Policy:  DOD,  interagency,  or  international  policy  that  impacts  the  other  seven 
non-materiel  elements. 

c.  Integrated  Logistics  Support  Elements 

Integrated  logistics  support  (ILS)  elements  are  a  set  of  12  items  that  are  used  to 
enable  system  readiness  and  availability.  The  12  ILS  elements  are  shown  in  Figure  69. 


Design  Interface 


KEY  PSM  RESPONSIBILITY; 
INTEGRATED  PRODUCT  SUPPORT 
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Product  support  is  enabled  by  a  package  of  12  Integrated  Product  Support  (IPS)  elements 
designed  to  deliver  system  readiness  and  availability  while  optimizing  system  life  cycle  cost. 


Figure  69.  ILS  Elements  (from  Defense  Acquisition  University  2010) 


d.  PESTO 

PESTO  is  an  acronym  that  relates  to  measures  of  performance  or  readiness  (Webb 
and  Candreva  2006).  The  letters  in  PESTO  are  identified  below  (Department  of  Navy 
2015). 


•  Personnel — Represents  a  detailed  capture  of  individual  skills  that  affect  the 
ability  of  a  unit  to  perform  its  mission 
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•  Equipment — Represents  the  equipment  material  condition  for  performing 
each  assigned  capability 

•  Supplies — Represents  the  availability  of  supplies  necessary  for  performing 
each  assigned  capability 

•  Training — Represents  the  performance  and  experience  of  the  crew  for 
performing  each  assigned  capability 

•  Ordnance — Represents  the  standardized  distribution  load  allowances  available 
for  performing  each  capability 

D,  FUNCTIONAL  REQUIREMENTS 

A  functional  requirement  is  distinguished  from  other  requirements  by  its  emphasis 
on  what  it  is  the  system  is  “required  to  do”  (Halligan  2014).  It  was  important  to  consider 
how  functional  requirements  would  be  incorporated  into  and  become  a  part  of  DSHEL.  In 
addition  to  this,  functional  flow  diagrams  depicted  the  main  aspects  and  sub  components 
of  some  of  the  key  functional  requirements  and  are  shown  throughout  this  section. 
Requirements  must  be  worded  in  such  a  way  that  they  are  clear  and  to  the  point,  not  open 
to  interpretation.  Unclear  requirement  wording  can  end  in  an  unsatisfactory  final  product 
and  re-work. 

The  DSHEL  team  did  not  write  the  requirements  for  the  HEL  system.  Any 
requirements  for  the  HEL  system  itself  were  not  within  the  control  of  the  DSHEL  team 
due  to  the  current  developmental  status  of  HEL.  While  it  was  not  within  the  team’s 
jurisdiction  to  dictate  DSHEL’s  requirements,  there  are  several  areas  that  were 
recognized  as  being  worthy  of  suggestion.  It  would  have  been  possible  for  the  team  to 
branch  out  into  other  areas  as  well;  security,  equipment  mean  time  between  failures 
(MTBE),  and  logistical  requirements  could  have  been  the  focus.  Data  transfer  and  the 
platform  of  interest  (HEL)  were  singled  out  because  of  their  immense  impact  on  the  basic 
functions  of  a  DS  system.  These  were  considered  to  be  the  monitoring  of  environmental 
and  internal  statuses  of  components  of  the  system  and  the  subsequent  sharing  (data 
transmission)  of  that  information. 

Some  examples  of  functional  requirements  the  DSHEL  team  considered  included 
the  following: 


131 


•  Distance  support  shall  remotely  monitor  data,  without  any  on-site  assistanee 
when  operating  at  working  conditions. 

•  Distance  support  shall  transport  monitored  data  to  off-site  recipients. 

•  Distance  support  shall  transport  data/information  between  off-site  and  on-site 
recipients. 

•  Data  transmitted  for  data  support  shall  be  in  a  pre-set  format. 

The  reason  that  data  transfer,  storage,  and  processing  were  foeused  on  as  major 
areas  were  due  to  the  faet  that  resourees  were  not  infinite.  The  DSHEL  team  had  to 
consider  during  the  design  proeess  that  there  would  be  limitations.  Considerations  were 
how  much  data  could  be  transferred,  how  much  data  could  be  stored,  and  how  fast  and 
frequently  data  could  be  transferred. 

In  order  to  better  express  how  data  size  and  transmission  capabilities  were  linked 
into  the  frequency  with  which  data  can  be  obtained,  the  following  example  was  used  to 
demonstrate  the  relationship  between  “pipe  size,”  or  the  data  restriction  a  system  is  under 
to  transport  data,  “data  size,”  or  the  amount  of  data  trying  to  be  transported,  and  their 
relationship  to  time.  The  combination  of  a  small  mode  of  transport  and  a  large  amount  of 
data  will  cause  the  system  to  be  slower  in  obtaining  and  transmitting  data,  just  as  the 
opposite  combination  would  cause  a  faster  transmission.  Figure  70,  gives  a  visual  of  this 
idea  using  four  common,  standard  link  speeds. 
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Effects  of  Link  Speed  (Mb/s)  and  Data  Size  (MB)  on  Data  Transfer  Time  (Hours) 


Each  of  the  four  lines  in  Figure  70  represented  a  different  technology,  which  was 
in  turn  associated  with  a  link  speed  in  kbps.  These  link  speeds  were  divided  by  a  generic 
data  size  in  KB,  whieh  were  varied  incrementally  from  one  to  one  hundred  KB  and  then 
divided  by  3600  to  convert  these  chosen  link  speeds  to  hours.  The  graph  is,  therefore, 
indieative  of  the  difficulties  of  attempting  to  transfer  large  amounts  of  data  over  low  link 
speeds  as  shown  by  the  slope  of  eaeh  line.  The  steeper  the  slope,  the  more  time  it  would 
take  for  data  to  be  transmitted.  For  example  for  10  KB,  HF  takes  0.0139  hours,  or  0.834 
minutes,  while  the  SHF/EHF  takes  2.96*10'^  hours,  or  0.0018  minutes.  As  a  result,  the 
requirements  were  suggested  to  include;  amount  of  data  transferred,  mode  of  data 
transfer,  amount  of  “pipe”  or  transfer  medium  available,  neeessary  frequeney  with  which 
data  needs  to  be  obtained,  and  the  form  in  whieh  data  shall  be  transmitted  and  reeeived 
in. 

The  importanee  and  potentially  severe  impaet  of  data  is  detailed  in  Figure  71; 
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Figure  7 1 .  Sample  Funetional  Flow  for  Data 


After  the  above  internal  eonsideration  of  functional  requirements,  the  DSHEL 
team  consulted  the  Distance  Support  Handbook  to  consider  what  pre-existing 
requirements  study  had  been  done  with  regards  to  DS.  From  this  handbook,  19  key 
requirements  were  obtained  (Naval  Surface  Warfare  Center,  Port  Hueneme  Division 
2013): 

1.  “The  system  architecture  shall  provide  real-time  communication.  Real 
time  communication  includes  chat,  telephone,  interactive  video,  etc.,  from 
shipboard  to  shore  personnel  and  vice  versa.” 

2.  “The  system  architecture  shall  provide  system  status  or  health  of  the 
system.  System  status  data  will  include  indicators  of  whether  a  system  or 
equipment  is  operational,  off-line,  degraded,  or  failed.” 

3.  “The  system  architecture  shall  extract  and  record  diagnostics  data  to  a 
system  attached  or  networked  storage.  Data  includes  information  to 
remotely  isolate  failure  to  a  single  component  at  the  Lowest  Replaceable 
Unit  (LRU)  method  from  post  analysis  or  specific  BIT  capabilities  run  at  a 
periodic  or  aperiodic  basis.” 

4.  “The  system  architecture  shall  provide  shore-based  remote  reconfiguration 
to  correct  hardware  failures.  It  may  require  a  realignment  of  a  klystron, 
radar  receiver,  optical  system,  etc.” 
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5.  “The  system  architecture  shall  collect  information  that  is  available  for 
supporting  immediate  troubleshooting  of  a  casualty  and  is  typically  not 
used  for  trend  or  historical  analysis.” 

6.  “The  system  architecture  shall  include  periodic  information  regarding 
environmental  conditions.  Environmental  monitoring  data  will  be  defined 
for  each  system’s  architecture  component.  This  includes  information  that 
is  primarily  used  for  trend  analysis  and  CBM  to  provide  overall  indicators 
of  system  performance.” 

7.  “The  system  architecture  shall  contain  information  that  is  available  for 
supporting  immediate  troubleshooting  of  a  casualty.  This  includes 
information  that  is  driven  by  configuration  changes  to  hardware,  software, 
and  firmware.” 

8.  “The  system  architecture  shall  allow  the  shore -based  Subject  Matter 
Expert  (SME)  determine  data  that  is  pertinent  for  DS  and  defines  the 
frequency  in  which  the  data  is  pulled  from  the  ship.  Data  location  can  be 
viewed  or  captured  by  an  inherent  or  external  monitoring  system.” 

9.  “The  system  architecture  shall  provide  shipboard  data  reduction  capability 
to  support  reduced  bandwidths  or  transmission  of  data  for  periodic  or 
aperiodic  data  reports.  This  refers  to  the  compression  of  data  before 
periodic  data  transmission  or  storage.” 

10.  “The  network  communication  layer  shall  include  a  data  transmission  path 
from  ship  to  shore;  either  directly  from  the  shipboard  system  to  the  Global 
Information  Grid  (GIG)  or  indirectly  via  an  interconnect  proxy  which  is 
already  connected  to  the  GIG.  This  includes  bandwidth  requirements  that 
will  vary  based  on  the  type  of  DS  being  implemented  and  the  data  type. 
This  also  includes  the  fixed  Minimum  Transmission  Unit  (MTU) 
roundtrip  delay  time  from  ship  to  shore.  The  MTU  for  each  DS  tool 
implemented  must  be  set  to  be  greater  than  the  fixed  MTU  from  ship  to 
shore.” 

11.  “The  shore-based  infrastructure  shall  include  common  sys tern/ equipment 
reported  data  (e.g.,  health  status,  environment  monitoring  data,  system 
faults,  event  data  recording)  repository  located  at  a  central  shore -based 
site.  This  data  repository  differs  from  the  Data  Aggregation  Center  as  it 
maintains  raw  system  data  before  being  reviewed/analyzed  and  aggregated 
with  other  data/metrics  by  a  system  SME.” 

12.  “The  shore-based  infrastructure  shall  provide  near-real-time  collaboration. 
Near  real  time  communication  includes  email,  recorded  video,  etc.,  from 
shipboard  to  shore  personnel  and  vice  versa.” 
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13.  “The  DS  infrastructure  components  shall  have  appropriate  Defense 
Information  Systems  Agency  (DISA)  Security  Technical  Implementation 
Guide  (STIG)  controls  applied.” 

14.  “The  shore-based  infrastructure  shall  provide  algorithms  used  by  the  shore 
data  architecture  (and  supporting  information  systems)  that  incorporate 
operational,  health,  and  readiness  data  to  develop  prognostic  and 
predictive  failure  analyses  prior  to  failure.” 

15.  “The  shore-based  infrastructure  shall  provide  shore-based  personnel  to 
have  access  to  all  technical  documentation  required  to  support  the  Fleet.” 

16.  “The  shore-based  infrastructure  shall  provide  access  to  data  that  provides 
on-board  parts  availability,  estimated  delivery  dates  or  status,  shore 
inventory,  part  location,  condition/repair  code,  and  ship  requisition 
information.” 

17.  “The  shore-based  infrastructure  shall  provide  access  to  Hardware, 
Software,  and  Firmware  configuration  information  that  is  installed  in  the 
shipboard  system.  Also  includes  configuration  data  on  allowance  parts  list 
(APT)  /  allowance  equipment  list  (AEL),  technical  bulletins,  and  technical 
manuals.” 

18.  “The  computing  infrastructure  shall  define  the  ability  of  aggregating 
system  data  and  to  send  that  data  via  the  system  architecture  for 
transmission  on  the  internal  network  or  external  communication  transport 
defined  by  the  data  transmission  path.  Network  access  for  data  assumes 
automated  capability  through  system  interfaces  without  shipboard 
personnel  interface.” 

19.  “The  shore -based  infrastructure  shall  provide  current  status  of  issues, 
historical  record  of  what  has  been  accomplished  to  resolve  the  issue,  who 
is  assigned  to  work  problem,  and  priority  or  classification  of  issue.  This 
information  will  be  used  for  turn-over  between  SME  or  to/from  ISEA  to 
RMC.” 

The  second  key  category  that  was  focused  on  for  requirements  was  the  platform 
of  interest,  or  HEE.  Any  system  that  is  placed  on  a  ship  will  be  subjected  to  an  extremely 
harsh  environment.  Equipment  will  be  exposed  to  salt,  temperature  extremes,  moisture, 
corrosion,  thermal  damage,  as  well  as  overall  wear  and  tear  from  intended  use.  It  was 
important  to  consider  the  basic  components  or  lowest  replaceable  units  (ERUs)  of  a  laser 
system.  Understanding  the  LRUs  of  the  HEE  allowed  the  team  to  consider  what  would  be 
important  to  focus  on  for  monitoring  the  HEE  system  for  distance  support. 
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The  purpose  of  distance  support  is  to  collect  information  on  the  status  of  the 
system.  For  FIEL,  there  are  various  areas  that  were  key  to  effectively  supporting  the 
system.  Requirements  relating  to  the  platform  of  interest  include: 

•  Temperature  of  various  elements  of  HEL  shall  be  monitored.  These  elements 
include  but  are  not  limited  to: 

o  Mirrors 

o  Elashlamp/Diode/Eiber 
o  Easing  medium 
o  Chamber 

•  System  shall  monitor  the  motion  and  positioning  of  all  components 

•  System  shall  monitor  degradation  and  status  of  the  lasing  material 

These  functional  requirements  combined  into  a  flow  diagram  would  be  as 
illustrated  in  Eigure  72. 


Eigure  72.  Sample  Eunctional  Elow  for  FIEL  Monitoring 


E.  PERFORMANCE  REQUIREMENTS 

Performance  requirements  reflected  the  functional  requirements  in  terms  of 
subject.  Flowever,  the  difference  between  the  two  types  of  requirements  is  that  while  a 
functional  requirement  states  what  the  system  will  do,  a  performance  requirement  is 
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concerned  with  to  what  extent  or  “how  well  the  system  is  to  do  what  it  is  to  do.” 
(Halligan  2014) 

As  requirements  eonsiderations  were  developed,  the  eoneept  of  “ilities”  or  how  a 
system  would  aetually  perform  the  aforementioned  requirements  were  eonsidered. 
Performanee  requirements  were  elosely  related  to  these  “ilities.”  In  order  for  the 
requirements  analysis  to  tie  into  the  eost  analysis  portion  of  the  eapstone,  the  number  of 
requirements  would  be  neeessary  for  ealculations.  However,  as  far  as  the  “ilities”  were 
eoneerned,  no  tally  was  neeessary  as  the  Level  of  Serviee  Requirements  assessment  is 
performed  differently.  Instead  the  COSYSMO  model,  which  is  utilized  in  the  eost 
estimation  analysis,  required  levels  of  use.  For  example,  COSYSMO  used  the  terms 
“very  high,  high,  medium,  and  low,”  in  plaee  of  a  numerieal  tally. 

Performance  requirements  with  regards  to  DSHEL,  whieh  were  a  eontinuation  of 
the  19  funetional  requirements  detailed  above,  should  answer  the  following  questions 
once  a  HEL  PoR  exists: 

•  DSHEE  shall  transport  data  at  X  speed. 

•  DSHEE  shall  monitor  temperature  of  eritieal  eomponents. 

•  DSHEE  shall  monitor  alignment  of  all  ealibrated  eomponents. 

•  DSHEE  shall  monitor  the  health  status  of  all  eomponents. 

•  DSHEE  shall  eolleet  a  X  level  of  information  to  be  available  to  SMEs. 

•  DSHEE  shall  provide  eolleet  data  at  X  intervals. 

•  DSHEE  shall  transfer  data  at  X  rate  to  the  host  platform. 

•  DSHEE  shall  monitor  system  vibration. 

Performanee  requirements  were  neeessary  to  take  the  next  step  in  product 
development.  After  the  funetional  requirements  had  established  the  non-negotiable  needs 
of  the  system  design,  the  performanee  requirements  added  the  quantitative  values  to  eaeh. 

F.  SUMMARY 

As  with  the  previous  discussion  of  requirements  language  and  their  genesis,  it  is 
important  to  understand  the  origin  of  these  eoneepts.  However,  it  was  the  intent  of  the 
DSHEE  team  to  apply  these  eoneepts  to  distanee  support,  rather  than  to  deseribe  them 
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abstractly.  KPPs,  KSAs,  MOEs,  and  MOPs  were,  therefore,  suggested  to  be  primarily 
foeused  in  the  same  areas  as  the  requirements  diseussed  above,  namely  data  transfer  and 
the  POL  A  functional  or  performance  requirement  is  an  answer  to  a  question  that  either 
focuses  on  what  the  system  is  to  do,  or  the  degree  to  which  it  is  to  do  it.  There  were 
partieular  areas  of  interest  for  future  requirements:  data,  its  handling,  proeessing  and 
transfer,  and  the  POL  Since  a  functional  requirement  is  a  statement  about  what  the  system 
is  to  do,  the  first  step  was  to  lay  out  simply  what  distanee  support’s  funetions  were.  DS 
involves  obtaining,  analyzing,  and  transmitting  information  and  data.  Funetional 
requirements  ean  be  understood  to  be  the  qualitative  analysis  of  a  system.  The  funetional 
requirements  (19)  eame  from  the  Distanee  Support  Handbook  and  were  then  expanded 
upon  in  the  performanee  requirements.  Clearly,  there  would  be  more  than  19  high  level 
funetional  requirements  if  the  latter  two  DS  Pillars  were  ineluded.  For  both  performance 
and  functional  requirements,  it  was  vital  to  the  final  integrity  of  the  system  to  remember 
that  requirements  must  be  clear,  not  be  open  to  interpretation.  Clear,  distinct  requirements 
were  the  key  to  ensuring  that  the  resultant  DSHEF  system  was  representative  of  the 
original  idea  for  the  system.  Clarity  that  would  affeet  not  only  the  requirements  written, 
but  also  the  subsequent  KPPs,  KSAs,  MOPs  and  MOEs  whieh  in  turn  define  the  true 
blueprint  of  the  system  and  therefore  the  system  itself.  Requirements,  KPPs,  KSAs, 
MOEs,  and  MOPs  were  infiueneed  heavily  by  the  POI,  DS  requirements  and  needs,  as 
well  as  seeurity,  resource  management  and  usability  eoneems. 
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IV.  CONCEPT  DEFINITION  AND  DESIGN 


This  chapter  discusses  the  architectural  approach  that  was  employed  in  the 
development  of  DSHEL,  as  well  as  the  design  method  and  the  actual  artifact  that  came 
out  of  the  application  of  the  design  process.  In  addition  to  this,  a  discussion  of  the  method 
that  would  be  used  in  order  to  test  and  evaluate  the  design  as  well  as  the  validation  and 
verification  that  the  design  satisfies  the  requirements  discussed  in  the  previous  chapter. 

A,  ARCHITECTURAL  DESIGN  APPROACH 

The  approach  for  the  architecture  design  was  twofold  in  nature.  First  a  framework 
was  developed  for  the  application  of  DS  for  maritime  tactical  weapon  and  sensor 
systems.  Second  this  framework  was  applied  to  a  specific  use  case  for  a  HEL  system, 
hereafter  called  the  DSHEE  system.  Eevis  defined  an  analytical  systems  engineering 
process  that  begins  with  the  system’s  operational  concept  and  includes  the  development 
of  three  separate  architectures  (functional,  physical,  and  allocated)  as  part  of  the 
decomposition  (Eevis  1993).  This  section  will  provide  an  overview  of  these  three 
architectures. 

1,  Functional  Architecture 

Before  going  into  the  approach  that  was  used  for  developing  the  functional 
architecture,  it  was  important  to  clarify  terminology  for  functional  architectures,  as  this 
was  critical  to  establishing  an  understanding  of  the  logical  aspects  of  a  system. 

a.  Functional  Architecture  Terminology 

When  considering  the  functional  architecture  of  a  system,  it  was  necessary  to 
distinguish  between  a  system’s  modes,  states,  and  functions.  A  system  mode  was  defined 
to  be  a  distinct  operating  capability  during  which  some  or  all  of  the  system’s  functions 
may  be  performed  to  a  full  or  limited  degree.  These  modes  may  be:  the  operational  mode, 
a  maintenance  mode,  or  a  particular  failure  mode.  The  DS  framework  that  was  developed 
for  DSHEE  was  designed  to  be  able  to  understand  the  nature  of  the  operational  mode  of 
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the  HEL  system,  detect  when  the  HEL  system  had  entered  a  particular  failure  mode  and 
respond  accordingly. 

A  system  state  was  defined  as  a  static  moment  in  time  of  the  set  of  metrics  or 
variables  needed  to  describe  in  detail  the  system  capabilities  to  perform  the  system’s 
functions.  In  general,  the  state  of  the  system  can  be  described  by  a  list  of  state  variables  at 
a  particular  point  in  time  (Buede  2009).  The  state  variables  do  not  change  over  time; 
however,  the  value  of  each  of  the  state  variables  does  change.  The  DSHEE  system  stored 
these  state  variables  of  the  HEE  system  and  performed  analysis  over  time  to  determine 
whether  the  HEE  system  was  staying  within  its  operational  mode. 

A  system  function  was  defined  as  a  process  that  takes  inputs  and  transforms  them 
into  outputs.  A  function  was  defined  as  a  transformation  and  had  the  potential  to  change 
the  state  of  the  system.  A  function  had  a  set  of  criteria  under  which  it  could  be  activated. 
The  set  of  criteria  included  both  the  availability  of  physical  resources  and  the  arrival  of  a 
triggering  input  (Buede  2009).  A  function  also  had  an  exit  criterion,  which  determined 
when  the  transformation  of  the  input  information  into  output  information  was  complete. 

b.  Functional  Architecture  Development 

The  Integrated  Definition  for  Eunctional  Modeling  (IDEEO)  was  chosen  as  an 
applicable  model  for  DSHEE.  IDEEO  is  a  graphical  representation  of  the  interactions  of 
the  functional  and  physical  elements  of  a  system.  A  function  or  activity  was  represented 
by  a  box  and  was  described  by  a  verb-noun  phrase  and  numbered  to  provide  context 
within  the  model.  The  inputs  and  outputs  to  and  from  the  function  are  represented  by 
arrows  entering  from  the  left  and  leaving  from  the  right  of  each  box.  Additionally, 
controls  or  conditions  under  which  the  function  may  occur  are  shown  by  arrows  entering 
the  top  of  the  box.  Einally,  mechanisms  or  the  physical  resource  required  to  perform  the 
function,  are  shown  by  arrows  entering  the  box  from  the  bottom  (National  Institute  of 
Standards  and  Technology  1993).  The  Eigure  73  demonstrated  this  basic  syntax. 
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Control 


Input 


►  Output 


Mechanism 

Figme  73.  IDEFO  Syntax 


The  context  diagram  defines  the  inputs,  controls,  outputs,  and  mechanisms  for  a 
single,  top-level  fimction,  labeled  AO.  The  context  page  establishes  the  boimdaiies  of  the 
system  or  organization  being  modeled.  Other  pages  of  the  model  represent  a 
decomposition  of  a  fimction  on  a  higher  page  following  the  same  syntax. 

2.  Physical  Architecture 

The  physical  architectine  of  a  system  was  the  hierarchical  description  of  the 
resoiuces  that  comprise  the  system.  Tliis  hierarchy  began  with  the  system  and  the 
system’s  top-level  components  and  progressed  down  to  the  configuiation  items  that 
comprise  each  intermediate  component.  The  physical  architechue  can  be  described  either 
by  a  generic  or  instantiated  physical  arcliitechue  (National  Institute  of  Standards  and 
Technology  1993).  DSHEL  utilized  a  generic  physical  architecture  as  opposed  to 
instantiated  architectme  due  to  the  fact  that  the  DSHEL  system  was  theoretical. 

3.  Allocated  Architecture 

The  allocated  architectme  provided  a  complete  description  of  the  system  design 
including  the  functional  aichitectme  allocated  to  the  physical  architectme  (National 
Institute  of  Standards  and  Technology  1993).  For  the  DSHEL  system  this  concept  was 
defined  in  the  IDEFO  diagrams.  Tire  physical  comporrents  were  described  by  the 
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mechanisms  for  each  activity.  Each  physical  component  described  in  the  physical 
architecture  breakdown  was  described  by  a  specific  mechanism  in  the  IDEFO  models. 

The  IDEEO  architectme  framework  was  chosen  for  the  DSHEL  due  to  the  ciment 
emphasis  on  the  methods  of  support,  the  Six  Pillars,  promulgated  by  the  USN. 
Additionally,  this  provided  a  better  mechanism  to  determine  specific  attributes  that  would 
be  requir  ed  in  all  aspects  of  the  system. 

B.  ARCHITECTURAL  DESIGN 

This  section  details  the  applied  application  of  the  IDEFO  diagrams  created.  To 
assist  the  reader  m  imderstandiug  the  EDEFO  diagrams.  Table  1 1  is  provided  to  identify 
the  ICOM  references  as  they  apply  to  the  diagr  ams  presented  in  this  section. 


Table  1 1 .  ICOM  References 


Diagram  Number 

ICOM  Label 

Detailed  ICOM  Reference 

AO 

11 

HEL  System  Information 

AO 

12 

HEL  System  Casiralty  Report 

AO 

13 

Ship  Maintenance  Action  Form  for  HEL  System 

AO 

Cl 

System  Fairlts  Detected 

AO 

C2 

Technical  Sirpport  Reqirested 

AO 

oi 

Closed  Casiralty  Report 

AO 

02 

Fleet  Advisory  Message  Released 

AO 

03 

Closed  Ship  Maintenance  Action 

AO 

04 

Tech  Bulletin  Released 

AO 

05 

Parts  Ordered 

AO 

Ml 

DSHEL 

A1 

11 

HEL  System  Casualty  Report 

A1 

12 

Ship  Maintenance  Action  Form  for  ElEL  System 

A1 

13 

System  Baseline  Faults 

A1 

Cl 

Reported  System  Faults 

A1 

C2 

Technical  Support  Requested 

A1 

Ol 

Closed  Casiralty  Report 

A1 

02 

Fleet  Advisory  Message  Released 

A1 

03 

Closed  Ship  Maintenance  Action 

A1 

04 

Tech  Bulletin  Released 

A1 

05 

Parts  Ordered 
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Diagram  Number 

ICOM  Label 

Detailed  ICOM  Reference 

A1 

Ml 

Technical  Assistance  Interface  Component 

A2 

11 

HEL  System  Casiralty  Report 

A2 

Cl 

Technical  Support  Reqirested 

A2 

oi 

Performance  Data 

A2 

02 

System  Statirs  Data 

A2 

03 

Farrlt  Data  and  Error  Codes 

A2 

Ml 

Remote  Diagnostic  Component 

A3 

11 

Performance  Data 

A3 

12 

System  Status  Data 

A3 

13 

Farrlt  Data  and  Error  Codes 

A3 

14 

HEL  System  hifonnation 

A3 

Cl 

Technical  Sirpport  Requested 

A3 

C2 

Trorrbleshooting  Procedirres 

A3 

Ol 

System  Baseline  Faiths 

A3 

Ml 

Remote  Cormection  Component 

A4 

11 

HEL  System  hiformation 

A4 

Cl 

System  Fairlts  Detected 

A4 

Ol 

Reported  System  Faults 

A4 

Ml 

Remote  Monitoring  Component 

This  section  also  covered  the  proposed  system/subsystem  decomposition  requhed 
by  the  physical  architectiue  breakdown.  The  system  level  interface  diagrams  detail  the 
major  interfaces  between  the  HEL  system  and  DSHEL,  as  well  as  DSHEL  and  the 
shipboard  network. 

1.  Integrated  Definition  for  Functional  Modeling  (IDEFO) 

Fust,  the  context  diagram  for  the  DSHEL  system  was  developed,  as  shown  m 
Figure  74.  As  described  in  the  previous  section,  the  context  diagram  provides  the  top- 
level  description  of  the  system  being  discussed.  The  top-level  fimction  for  the  DSHEL 
system  was  to  provide  distance  support  services.  In  order  to  provide  DS  services  for  the 
HEL  system,  the  DSHEL  system  required  HEL  system  information.  Additionally,  since 
this  system  was  shidied  as  it  applied  for  shipboard  tactical  systems,  a  HEL  CASREP  or  a 
sliip  maintenance  action  form  for  the  HEL  system  woirld  also  be  reqirued.  These  artifacts 
woirld  provide  rrsefirl  mformation. 
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The  controls  that  triggered  the  function  of  DS  being  provided  were  “System 
Faults  Detected”  and  “Technical  Support  Requested.”  The  outputs  for  DS  services 
included  “Closed  Casualty  Report,”  “Fleet  Advisory  Message  (FAM)  Released,”  “Closed 
Ship  Maintenance  Action,”  “Tech  Bulletin  Released,”  or  “Parts  Ordered.” 


System  Faults  Detected  Technical  Support  Requested 

T  I 

I  liiL  System  Information - ►  ^  ..  r-,.-  ►Closed  Casualtv  Report 

Provide  Distance  - ►Fleet  AdvLsoo  Message  Retecd 

HEL  System  Casualt)  Report - ►  Support  Services  - ►Closed  Ship  Maintenance  Action 

- ►Tech  Bulletin  Released 

Ship  Maintenance  Action  Form  for  I  lEL  System - ►  q  - ►Parts  Ordered 

A 

AO 

DSHF.l. 

NODE:  DS/A-0  TITLE:  Provide  Distance  Support  Services  NO.:  P.l 

Figure  74.  Context  Diagram 

Once  the  context  diagram  was  completed,  the  next  diagram  broke  out  the  top  level 
function  into  major  sub  functions.  In  the  case  of  the  DSHEL  system,  those  major 
functions  were  each  of  the  pillars  of  DS.  This  diagram  is  shown  below  in  Figure  75.  Per 
the  design  standards  for  IDEFO  diagram’s  higher-level  inputs,  controls,  outputs,  and 
mechanisms  (ICOMs)  are  shortened  to  I,  C,  O,  and  M  respectively.  The  number  assigned 
to  each  ICOM  was  determined  by  the  position  in  the  higher-level  diagram  from  top  to 
bottom  or  left  to  right.  This  diagram  demonstrates  that  the  inputs  related  to  CASREPs 
(12)  and  maintenance  action  forms  (13)  were  inputs  into  the  first  DS  function  “Provide 
Remote  Technical  Assistance”  as  well  as  the  output  from  box  3  “System  Baseline 
Eaults.”  The  controls  which  activate  the  “Provide  Remote  Technical  Assistance”  function 
were  “Technical  Support  Requested”  (C2)  or  the  output  from  function  box  4  “Perform 
Remote  Monitoring,”  which  were  detected  system  faults. 
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All  outputs  from  the  context  diagram  came  from  the  first  function.  Further 
analysis  determined  that  this  is  due  to  organizational  constraints  within  the  USN. 
Currently,  the  policy  for  the  USN  is  that  all  DS  is  initiated  by  the  Fleet  although  from  a 
shore  perspective,  it  may  be  possible  to  reach  into  the  system  remotely  to  provide 
support.  This  is  not  possible  without  Fleet  approval,  and  any  information  gained  from 
these  remote  sessions  is  fed  back  via  email.  While  this  is  the  case  currently,  it  can  be 
inferred  that  at  a  later  time  this  policy  may  change,  and  it  would  be  possible  to  see  the 
main  outputs  shift  to  the  other  functions  of  DS.  The  mechanism  for  box  1  was  the 
technical  assistance  interface  component. 

The  second  function  was  shown  in  box  2  “Perform  Remote  Diagnostics.”  The 
input  for  this  function  was  “HEL  System  Information”  (12).  The  control  under  which  this 
function  was  activated  was  “System  Faults  Detected”  (C2).  This  function  produced 
several  outputs;  the  first  output  from  this  function  was  “Performance  Data,”  which  would 
be  related  to  the  performance  of  the  HEL  system.  This  information  may  include  elements 
such  as:  the  amount  of  beam  jitter  that  exists,  the  power  output  of  the  battery  storage 
system,  the  beam  quality,  and  the  cleanliness  of  the  director  mirrors.  The  second  output 
of  function  2  was  “System  Status  Data.”  This  category  could  include  the  status  of  link 
data  cables  for  the  HEL  system  and  whether  all  major  subsystems  were  reporting 
operational.  The  last  output  from  function  2  was  “Eault  Data  and  Error  Codes”  this  may 
include  application  error  codes  being  reported  from  the  HEL  system,  or  the  results  from 
BIT  from  the  HEL  system.  The  mechanism  under  which  function  2  was  completed  was 
the  “Remote  Diagnostic  Component.” 

The  third  function  was  shown  in  box  3  “Perform  Remote  Repair  and  Validation.” 
In  addition  to  “HEL  system  information”  (H),  this  function  took  all  the  outputs  from 
function  2.  The  controls  for  the  activation  of  this  function  were  both  a  “Request  for 
Technical  Assistance”  and  “Trouble  Shooting  Procedures.”  Operationally  speaking,  when 
support  is  provided  remotely  to  a  system,  every  opportunity  is  made  to  obtain  as  much 
information  from  the  system  as  possible  before  attempting  a  remote  connection.  This 
connection  will  be  made  in  a  bandwidth  constrained  environment,  so  it  should  be 
accompanied  by  troubleshooting  procedures  to  minimize  the  duration  of  the  remote 
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connection.  The  output  from  this  funetion  was  the  collection  of  “System  Baseline  Faults.” 
These  “System  Baseline  Faults”  eould  inelude  a  missing  adaptation  load  or  a  network 
eonfiguration  setting  that  was  out  of  an  approved  baseline.  These  baseline  faults  are 
reported  baek  to  the  Fleet  through  email  (indicated  as  an  input  to  funetion  1).  The 
mechanism  under  which  function  3  was  accomplished  was  the  remote  eonnection 
eomponent. 

The  last  function  was  “Perform  Remote  Monitoring.”  This  was  the  proaetive  form 
of  DS  that  was  modeled.  The  input  to  this  funetion  was  “HEL  System  Information.”  The 
eontrol  under  whieh  this  function  was  activated  was  “System  Faults  Being  Deteeted.” 
What  this  implied  was  that  remote  monitoring  of  the  HEL  system  was  eontinuous  in 
nature  and  that  this  function  was  actually  the  report  out  of  system  faults.  This  function 
was  activated  when  a  system  fault  was  detected,  which  would  result  in  the  DSHEL 
system  reporting  out.  This  report  was  to  be  used  as  a  way  to  initiate  a  remote  tech  assist, 
indicated  by  showing  the  output  from  function  4  as  a  control  to  function  1.  The 
mechanism  under  which  function  4  was  performed  was  the  “Remote  Monitoring 
Component.” 
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Figure  75.  Provide  Distanee  Support  Serviees 


The  next  diagram,  A1  shown  in  Figure  76,  breaks  out  the  “Provide  Remote 
Teehnical  Assistanee”  function  into  various  sub-functions.  This  diagram  shows  three  sub¬ 
functions  that  make  up  the  top-level  function.  Function  1 1  was  “Provide  Email  Support.” 
All  the  outputs  shown  are  derived  from  this  function.  This  was  operationally  driven  rather 
than  system  driven.  The  other  outputs  that  should  be  noted  from  this  function  were  the 
request  for  chat  support  or  phone  support,  which  served  as  controls  for  the  other  two 
functions  in  this  diagram.  The  outputs  from  functions  12  and  13  are  shown  with  tunneling 
arrows,  which  indicates  that  they  are  not  shown  on  higher-level  diagrams.  This  was 
allowed  for  simple  functions  under  the  IDEFO  specifications.  This  was  used  when  the 
function  output  was  simple  and  did  not  relate  to  any  other  system  or  function.  The 
mechanisms  that  supported  each  of  these  functions  were  an  email  client,  chat  client,  and 
Voice  over  Internet  Protocol  (VoIP)  client. 
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Figure  76.  Provide  Remote  Teehnieal  Assistance 


The  next  function  that  was  broken  out  can  be  seen  in  A2  shown  in  Figure  77 
“Perform  Remote  Diagnostics.”  These  functions  include  “Observe  System  Performance,” 
“Observe  System  Status,”  and  “Observe  System  Faults”  (21,  22,  and  23  respectively). 
The  aforementioned  took  “HEL  System  Information”  as  an  input,  and  output  “System 
Performance  Data,”  “System  Status  Data,”  and  “Fault  Data  and  Error  Codes.”  The 
mechanism  under  which  each  of  these  functions  was  accomplished  was  the  “Performance 
Monitoring  Element,”  “System  Status  Monitoring  Element,”  and  the  “Eault  Detection 
Eault  Isolation  Element.”  This  function  was  not  broken  down  further  for  the  purposes  of 
DSHEE. 
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Figure  77.  Perform  Remote  Diagnosties 

The  next  deeomposed  funetion  was  A3,  “Perform  Remote  Repair  and  Validation.” 

illustrated  in  Figure  78.  The  first  sub  funetion  was  31  “Verify  Adaptation  Data  Load.” 

This  function  took  as  an  input  the  “HEL  System  Information”  and  provides  as  an  output 

“System  Baseline  Faults.”  The  mechanism  that  would  perform  this  function  was  the 

“Adaptation  Data  Checker.”  The  next  function  was  32  “Verify  Baseline  Configuration.” 

This  function  took  as  an  input  “HEL  System  Information”  and  provided  as  an  output 

“System  Baseline  Eaults.”  The  mechanism  that  would  perform  this  function  was  the 

“Configuration  Baseline  Manager.”  The  next  function  was  33  “Run  System  Diagnostic 

Tests.”  This  function  took  as  an  input  “HEL  System  Information”  as  well  as 

“Performance  Data,”  and  “Eault  Data  and  Error  Codes.”  The  mechanism  under  which 

this  function  was  performed  was  the  “System  Diagnostic  Tool.”  The  output  from  this 

function  was  “System  Baseline  Eaults.”  The  last  function  was  34  “View  System  Status 

Logs.”  The  inputs  to  this  function  are  “HEL  System  Information,”  and  “System  Status 
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Data.”  The  output  from  this  function  was  “System  Baseline  Faults”  and  the  mechanism 
under  which  this  function  was  performed  was  the  “Log  Viewer.”  All  of  these  functions 
would  be  performed  when  both  a  “Technical  Assistance  Request”  was  received  from  the 
Fleet  and  when  “Troubleshooting  Procedures”  had  been  developed  to  perform  the  remote 
repair  and  validation. 
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Figure  78.  Perform  Remote  Repair  and  Validation 

The  last  major  function  decomposed  was  A4  “Perform  Remote  Monitoring” 
shown  in  Figure  79.  This  was  the  proactive  type  of  DS  which  was  modeled  in  this 
capstone.  This  function  was  made  up  of  four  sub-functions  “Collect  System  Status 
Information,”  “Collect  Fault  Information,”  “Collect  Logs,”  and  “Collect  Performance 
Information.”  This  function  breakdown  was  very  similar  to  the  major  function  A2 
“Perform  Remote  Diagnostics.”  The  difference  between  these  two  functions  is  that,  in 
A4  the  DSHEL  system  was  continuously  monitoring  the  HEL  system  and  harvesting  data 
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which  was  analyzed  for  discrepancies  and  sent  back  to  shore  for  further  analysis  by  the 
SME.  All  of  these  functions  take  in  “HEL  System  Information”  as  the  main  input  and 
output  any  “Reported  System  Eaults.”  The  control  under  which  a  system  fault  would  be 
reported  is  “System  Eaults  Are  Detected.”  Eunction  41  was  performed  by  the  “System 
Status  Collection  Tool.”  Eunction  42  was  performed  by  the  “Eault  Analysis  Collection 
Tool.”  Eunction  43  was  performed  by  the  “Eog  Collection  Tool.”  Eunction  44  was 
performed  by  the  “Performance  Collection  Tool.” 
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Eigure  79.  Perform  Remote  Monitoring 
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2.  Proposed  DSHEL  System/Subsystem 

This  section  introduces  a  notional  DSHEL  system  sub-system  design  based  on  the 
IDEFO  diagram.  Figure  80  shows  a  physical  breakdown  hierarchy  tree,  which  conelates 
to  the  IDEFO  diagrams  discitssed  in  the  previorrs  section. 


Figirre  80.  Physical  Arcliitectme 


It  shoitld  be  noted  that,  althorrgh  the  physical  architectiue  depicted  separate 

physical  components  for  the  perfonnarrce  of  each  fimction,  in  reality  several  components 
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may  be  software  based  and  covered  imder  a  single  piece  of  software.  To  illustrate  this 
point,  a  notional  system  design  was  developed  to  show  both  the  physical  hardware  and 
software  components  as  depicted  in  Figme  81. 


Shipboard  Transport  Switch 
KVM  over  IP  Switch 

LCD  Tray 
KevOoarrt  Trav 
Cable  Organizer 

DSHEL  Sei-ver 
Storage/Backup 
Power/UPS 

Figme  8 1 .  Notional  DSHEL  Hardware  Architectme 

The  hardware  architectme  for  the  DSHEL  system  woitld  consist  of  a  high 
perforinance  rack  serwer  that  wortld  be  capable  of  hosting  two  separate  vutrral  machine 
envuonmerits.  Additionally,  secrrre  remote  cormection  into  the  DSHEL  system  wortld 
occur  tlnoirgh  the  use  of  an  enterprise  level  KVM  over  IP  switch.  Local  administration  of 
the  DSHEL  system  itself  coirld  occitr  through  the  use  of  the  keyboard  and  monitor  prrll 
orrt  tray.  Data  being  stored  on  the  system  for  trending  and  analysis,  as  well  as  backrrp  of 
the  virtiral  machine  environments,  wortld  be  satisfied  throrrgh  the  rrse  of  an  enterprise 
backrrp  sohrtion.  It  shorrld  be  noted  that  many  of  the  ftmctions  intenial  to  the  DSHEL 
system,  srrch  as  backrrp  and  local  administration,  were  not  captmed  in  the  IDEFO 
fimctional  analysis.  The  focits  was  on  the  distance  support  service  framework  and  not 
necessarily  the  DSHEL  system;  therefore,  this  fimctionality  was  not  inchrded.  If  this 
design  was  to  be  moved  forward,  it  woirld  be  advisable  that  the  scope  and  analysis  of  the 
IDEFO  architectme  be  decomposed  fitriher  to  inchrde  the  intenial  fimctionality  of  the 
DSHEL  system. 


155 


The  software  arehitecture  in  Figure  82  illustrates  a  notional  application  of 
software  to  implement  the  various  distance  support  services.  Modern  shipboard  hotel 
services  are  provided  using  a  Windows-based  environment.  Therefore,  it  was  determined 
that  the  technical  assistance  function  would  best  be  accomplished  by  leveraging  the 
existing  shipboard  infrastructure  for  email,  chat,  and  VoIP  services.  Additionally, 
although  not  shown  here,  the  DSHEL  system  would  also  inherit  many  of  the  information 
security  features  inherent  in  the  shipboard  network  such  as  Firewalls,  IDS/IPS,  and  host 
based  security.  The  main  applications  providing  the  functionality  for  remote  monitoring, 
diagnostics,  repair  and  validation  would  be  accomplished  by  the  Red  Flat  Enterprise 
Einux  operating  environment  hosting  the  various  data  processing  applications. 
Eeveraging  a  virtual  infrastructure  for  this  distance  support  operating  environment  allows 
for  better  redundancy  and  decoupled  the  hardware  and  software  environments,  which 
would  enhance  future  supportability  of  the  DSHEE  system. 


Eigure  82.  Notional  Software  Architecture 


The  hardware  and  software  architecture  for  the  DSHEL  system  are  independent  of 
the  HEL  system.  This  hardware  could  be  used  to  monitor  any  tactical  weapon  or  sensor 
system  on  a  ship.  It  should  be  noted  that  although  the  hardware  is  shown  as  a  separate 
rack  of  equipment,  every  attempt  should  be  made  to  integrate  this  equipment  into  the  host 

system  that  requires  DS  services.  This  would  leverage  the  existing  hardware  and  reduce 
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cost.  The  choice  of  software  was  based  on  existmg  best  practices  within  the  USN.  In 
general  Windows,  Red  Hat,  and  VMware  have  become  the  standaid  for  the  USN  when  it 
comes  to  OS  and  virtualization  softwar  e.  It  was  the  assumption  of  the  team  that  whenever 
possible,  the  choice  of  components  should  align  to  prescribed  USN  guidance. 

3.  Notional  DSHEL  to  HEL  Interface 

This  section  discusses  information  that  the  DSHEL  system  miglit  collect.  Figiue 
83  shows  a  notional  architectme  for  the  interface  between  the  DSHEL  system  and  the 
HEL  system. 
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DSHEL  will  be  collecting  system  performance  data,  as  well  as  system  faults  as 
they  occur.  The  basic  HEL  system  and  common  system  fairlt  detection  that  would  be 
onboard  USN  platforms  was  discirssed  next.  This  should  in  no  way  be  interpreted  as  an 
exhaustive  list  of  parameters  that  can  be  monitored  in  general;  these  parameters  were 
developed  given  the  assirmptions  at  the  time  of  DSHEL’s  creation.  This  list  woirld,  m  the 
firtiue,  reqrrire  fitrther  refinement  in  the  event  the  DSHEL  system  is  implemented. 

A  laser  weapon  damages  a  target  by  focirsing  a  beam  of  light  for  a  finite  period  of 
time  on  a  specific  aim  point.  The  effectiveness  of  the  weapon  system  depends  critically 
on  the  following  (Perram,  Salvatore,  Hengehold,  and  Fiorino  2010); 
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•  the  power  P  of  the  laser 

•  the  wavelength  of  light  X 

•  the  diameter  of  the  primary  mirror  / 

•  the  range  to  the  target  R 

•  the  dwell  time  Xd 

These  are  the  main  parameters  that  affect  the  performance  of  the  laser;  however, 
there  are  many  other  parameters  which  should  be  discussed  that  are  of  interest  from  a 
monitoring  perspective. 

The  irradiance,  with  typical  units  of  watts  per  centimeter,  represents  the  delivered 
laser  power  divided  by  the  beam  area. 

P 

Fluence,  or  energy  per  unit  area,  delivered  by  the  HEL  to  the  target  represents  the 
irradiance  accumulated  over  the  dwell  time,  and  is  defined  as: 

(  ^ 


The  laser  power,  wavelength,  and  mirror  diameter  are  parameter  associated  with 
the  laser  weapons  system,  whereas  the  range  and  dwell  time  depend  on  the  engagement. 
Typically,  these  types  of  parameters  are  grouped  separately: 

Where  the  collection  of  source  parameters  is  called  the  brightness: 

nP 
B 


AiA/oy 

The  system  Strehl  (S)  is  the  value  less  than  unity  representing  many  effects  that 
might  increase  the  effective  spot  size  beyond  the  diffraction  limit.  When  S=l,  the 
maximum  performance  is  achieved  and  the  brightness  is  diffraction  limited.  Strehl  is 
usually  defined  as  the  ratio  of  on-axis  irradiance  to  the  diffraction  -limited  on-axis 
irradiance: 
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Many  real-world  effects  are  buried  in  the  overall  system  Strehl,  including  jitter, 
atmospheric  turbulence,  thermal  blooming,  and  adaptive  optics  effectiveness.  The  details 
of  these  phenomena  are  critical  to  the  performance  of  most  HEL  weapon  systems 
(Perram,  Salvatore,  Hengehold,  and  Fiorino  2010). 

In  general,  the  DSHEL  system  collected  information  from  the  HEE  system  that 
could  be  used  to  determine  the  overall  beam  quality.  This  refers  to  monitoring  the  beam 
drift,  jitter,  scattering,  absorption,  turbulence,  and  thermal  blooming.  The  beam  control 
system  attempts  to  maintain  a  small  focused  spot  on  a  given  aim  point  throughout  an 
engagement.  Beam  control  can  be  thought  of  as  three  separate  categories  of  beam  control, 
acquisition,  and  beam  propagation. 

In  all  of  these  various  parameters,  the  assumption  was  made  that  the  HEE  system 
was  logging  and  monitoring  all  of  the  aforementioned  parameters  internal  to  the  HEE 
system.  Additionally,  the  assumption  was  made  that  the  acquiring  of  this  data  by  the 
DSHEE  system  can  be  made  through  simple  interfaces  either  from  standard  RJ45 
Ethernet  connections,  RS-232/RS-422  serial  connections,  or  USB  connections.  In  certain 
cases  it  may  be  necessary  to  collect  environmental  data  from  the  HEE  system  such  as 
ambient  temperature  around  the  HEE  system,  or  vibrational  information  from  the 
adaptive  optical  sub-system.  An  additional  assumption  was  made  that  this  data  was  also 
being  collected  by  the  HEE  system  and  could  be  acquired  through  standard  interfaces, 
and  that  the  data  was  transmitted  through  standard  protocols  such  as  UDP,  TCP/IP,  and 
SNMP. 


4.  Notional  DSHEL  to  Shipboard  Network  Interface 

In  addition  to  the  interface  between  the  DSHEE  system  and  the  HEE  weapons 
system,  there  also  exists  an  interface  between  the  DSHEE  system  and  the  rest  of  the 
shipboard  network.  Since  the  DSHEE  system  requires  off  ship  connectivity,  the  typical 
path  that  the  DSHEE  system  would  take  was  considered.  It  was  assumed  that  a  typical 

shipboard  environment  with  the  necessary  enclave  security  requirements  in  place  such 
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that  the  DSHEL  system  could  accept  secme  coimections  from  off  ship  as  well  as 
transport  data  off  ship  in  a  secme  manner.  Figiue  84  shows  a  typical  shipboard 
architecture. 


Figiue  84.  DSHEL  to  Shipboard  Network  hiterface 


Starting  from  the  DSHEL  system,  the  server  would  maintain  a  persistent 
connection  to  a  shipboard  edge  transport  switch.  Protection  at  the  transport  layer  for 
inboimd/outboimd  coimections  mtenial  to  the  network,  as  well  as  off  ship,  was  provided 
througli  the  employment  of  an  IDS  and  an  IPS.  An  IDS/IPS  is  a  network  seciuity 
appliance  that  monitors  network  traffic  for  malicious  activity.  From  the  IDS/IPS,  the  data 
was  passed  to  the  shipboard  core  tianspoil  switch.  Next,  the  signal  must  pass  through  the 
shipboard  firewall.  The  frmction  of  the  friewall  in  a  shipboard  envuonment  is  to  establish 
a  barrier  between  a  tiristed  secme  intenial  network  (shipboard)  and  another  network,  in 
this  case  the  SIPR/NTPR  network. 

Once  the  data  negotiates  through  the  friewall,  it  would  pass  througli  the  ADNS 
router,  and  priority  would  be  assigned  via  a  packet  shaper.  Finally,  all  traffic  flowing  off 
ship  goes  through  a  bulk  network  encryption  device.  It  was  assumed  for  the  purpose  of 
this  capstone  that  the  bandwidth  off  ship  was  constrained  and  that  significant  testing 
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would  need  to  be  aceomplished  in  order  to  ensure  that  the  level  of  distanee  support 
needed  by  the  HEL  system  eould  be  provided. 

The  eonfiguration  and  maintenance  of  this  connection  was  critical  to  the  ability  to 
provide  the  DS  capability.  As  such,  it  was  determined  that  it  would  be  necessary  to 
develop  a  service  level  agreement  (SLA)  that  would  describe  the  connection 
configuration  as  well  as  the  accepted  level  of  performance  in  order  to  provide  the  DS 
capability  for  the  HEL  system. 

The  entire  design  of  the  DSHEL  system  started  with  the  internal  functional 
analysis  of  the  system  describing  the  DS  services  which  DSHEL  provided  and  by 
utilizing  the  IDEEO  modeling  framework.  The  section  went  on  to  describe  the  physical 
architecture  of  the  DSHEL  system,  as  well  as  notional  hardware  and  software 
architectures.  Einally,  interface  requirements  were  considered  when  developing  the 
relationship  between  DSHEL  and  HEL,  as  well  as  between  DSHEL  and  the  shipboard 
environment. 

C.  TEST  AND  EVALUATION 

The  implementation  of  the  DSHEL  system  would  require  significant  testing  to 
ensure  requirements  for  DS  are  met.  This  section  discusses  the  testing  and  evaluation  that 
was  scoped  for  DSHEL.  In  addition  to  the  testing  and  evaluation  methodology  that  was 
determined  to  be  sufficient  to  meet  the  requirements  for  DSHEL,  as  well  as  each  of  the 
three  phases  of  testing  that  should  be  pursued  for  implementation  of  the  DSHEL  system. 
These  three  phases  of  testing  were  shore-based  testing,  transport  layer  testing,  and 
shipboard  testing. 

1.  Test  and  Evaluation  Methodology 

Several  types  of  test  and  evaluation  are  performed  depending  on  the  phase  and 
effectiveness  of  the  evaluation  effort.  These  testing  phases  are  broken  into  four  types  of 
testing.  Type  1  testing  would  take  place  during  the  initial  phase  of  detail  design  and 
covers  the  testing  of  system  components  for  function  and  performance.  This  would 
include  the  testing  of  various  operating  and  logistic  support  actions  that  are  directly 
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comparable  to  tasks  performed  in  a  real  operational  situation.  Type  2  testing  is  the  point 
when  preproduetion  prototype  equipment,  software,  and  formal  proeedures  are  available. 
Type  3  testing  would  eover  the  produetion  model  testing  at  designated  test  sites.  Type  4 
testing  would  be  conducted  during  operational  utilization  and  support  phase,  measuring 
the  system  utilization  rate  to  determine  the  total  system  effeetiveness  and  on  life-eycle 
eosts  (Blanchard  and  Fabrycky  2011). 

The  goal  of  testing  the  DSHEL  system  is  to  provide  assuranee  to  all  stakeholders 
that  requirements  and  objeetives  are  met.  It  is  assumed  that  onee  the  DSHEL  system 
design  had  been  formalized  and  exeeuted,  then  the  system  would  be  tested  in  aceordance 
with  a  formal  test  and  evaluation  master  plan  (TEMP)  that  was  assumed  to  be  part  of  the 
larger  HEL  aequisition  program.  An  assumption  was  made  that  all  testing  related  to  the 
DSHEL  system  would  align  elosely  with  the  developmental  and  operational  testing  of  the 
HEL  system.  Based  on  these  assumptions,  this  seetion  will  eover  in  more  detail  the  Type 
3  testing  that  would  oeeur  for  the  DSHEL  system.  More  detail  will  be  provided  to  outline 
a  phased  approaeh  to  testing  during  the  initial  operational  test  and  evaluation  (lOTE) 
phase  of  the  HEL  development.  This  will  include  a  shore-based  testing  phase,  transport 
layer  testing  phase,  and  shipboard  testing  phase. 

Testing  is  segregated  in  this  fashion  to  separate  the  major  interfaee  testing  from 
the  integration  testing.  The  shore  based  testing  will  be  used  to  test  the  DSHEL  system 
itself  and  the  major  interfaees  between  the  DSHEL  system  and  the  HEL  system.  The 
transport  layer  testing  will  evaluate  the  major  interfaces  between  the  DSHEL  system  and 
the  shipboard  network  in  a  land  based  facility  excluding  any  connection  with  the  HEL 
system  itself  Einally,  the  shipboard  end  to  end  testing  will  eover  full  integration  from 
HEL  to  DSHEL  to  shipboard  network. 

2.  Shore  Based  Testing 

The  shore  based  testing  ineludes  the  development  and  exeeution  of  system 
operational  verifioation  tests  (SOVT)  of  the  DSHEL  system  itself.  This  test  ensures  that 
both  eomponents,  hardware  and  software,  are  operating  as  required. 
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The  shore-based  test  also  assesses  all  of  the  major  interfaces  between  the  DSHEL 
system  and  the  HEL  weapon  system.  This  includes  testing  to  ensure  all  formats  of  the 
data  could  be  collected  from  the  major  subsystems  of  the  HEE.  The  testing  also  evaluates 
how  well  the  DSHEE  system  performs  each  of  the  major  DS  functions  using  approved 
measures  of  effectiveness  (MOEs). 

3.  Transport  Layer  Testing 

The  transport  layer  testing  demonstrates  the  connection  between  the  DSHEE 
system  and  the  shipboard  transport  layer.  This  also  includes  testing  the  connection 
between  the  ship  and  shore;  it  is  used  to  validate  the  functionality  of  the  DSHEE  over  a 
low  bandwidth  connection  in  a  controlled  environment  and  includes  two  tests.  The  first 
test  covers  the  usability  of  the  DSHEE  system  as  a  function  of  bandwidth.  The  second 
test  covers  the  usability  of  the  DSHEE  system  as  a  function  of  overall  satellite  delay.  The 
bandwidth  test  would  determine  the  lowest  acceptable  bandwidth  in  which  the  DSHEE 
system  can  operate  while  remaining  fully  functional.  The  satellite  delay  test  would 
determine  the  longest  delay  time  the  DSHEE  system  can  operate  with  before  the 
connection  was  lost. 

4.  Shipboard  Testing 

The  shipboard  testing  was  the  final  phase  in  support  of  the  DSHEE  system 
integration.  This  testing  consisted  of  an  end-to-end  test  from  shore  to  HEE.  It  is  advisable 
that  this  testing  be  conducted  in  conjunction  with  the  installation  of  the  DSHEE  system 
on  a  specific  platform,  which  would  usually  coincide  with  a  ship  restricted  availability 
(SRA).  After  installation  of  the  DSHEE  system  on  a  particular  ship  platform,  a  SOVT 
was  performed  on  the  DSHEE  system.  This  test  included  various  internal  components  of 
the  DSHEE  system  as  well  interfaces  to  the  HEE  system  and  the  shipboard  network. 
Eollowing  the  end  of  the  SRA  period,  an  underway  test  needs  to  be  conducted  to  ensure 
the  DSHEE  system  is  communicating  to  shore  via  satellite. 

Taking  this  phased  approach  to  the  testing  and  integration  of  the  DSHEE  system 

was  very  indicative  of  the  ISEA  process  for  testing  used  to  bring  a  new  installation  onto  a 

ship.  This  approach  allows  the  ISEA  and  the  OEM  to  determine  at  each  phase  of 
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development  whether  the  design  is  mature  enough  and  effectively  identify  any  difficulties 
with  the  design  prior  to  installation  on  ship.  This  would  mitigate  the  overall  risk  to  final 
installation  and  use  of  the  DSHEL. 

D,  VERIFICATION  AND  VALIDATION 

Verification  and  validation  are  procedures  used  together  to  check  that  the  DSHEL 
system  meets  the  requirements  and  specifications  and  that  it  fulfills  its  intended  purpose. 
The  Project  Management  Book  of  Knowledge  (PMBOK)  defines  verification  and 
validation  as  (Project  Management  Institute  2004): 

•  Validation:  the  assurance  that  a  product,  service,  or  system  meets  the  needs  of 
the  customer  and  other  identified  stakeholders.  It  often  involves  acceptance 
and  suitability  with  external  customers. 

•  Verification:  the  evaluation  of  whether  or  not  a  product,  service,  or  system 
complies  with  regulation,  requirement,  specification,  or  imposed  condition.  It 
is  often  an  internal  process. 

In  general,  verification  is  focused  on  determining  whether  the  system  meets  the 
requirement  of  design.  Validation  is  focused  on  whether  the  system  meets  the  operational 
needs  of  the  user. 

1,  Verification  and  Validation  Methodology 

The  first  step  to  understanding  whether  the  requirements  of  a  system  have  been 
met,  is  to  understand  which  characteristics  of  the  system  require  evaluation  and 
assessment.  Many  systems  in  the  field  today  lack  the  necessary  feedback  into  true 
operation.  It  is  for  this  reason  that  it  is  important  to  understand  what  factors  need  to  be 
measured  and  what  information  is  required  to  be  monitored  and  recorded  (Blanchard  and 
Eabrycky  2011).  Once  the  data  requirements  were  defined,  the  next  step  was  to  design  the 
DSHEL  system  to  collect  this  information  appropriately.  Chapter  II  discussed  the  process 
by  which  the  determination  would  be  made  for  data  that  needed  to  be  collected  and 
monitored.  Once  this  determination  has  been  made,  it  is  necessary  to  verify  that  the  data 
was  correct.  If  the  determination  is  made  that  the  data  reveals  issues  with  HEL,  it  is 
important  to  next  consider  how  this  information  could  be  used  to  inform  the  program  of 
design  changes  that  might  need  to  be  made. 
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2,  Verification  and  Validation  Analysis 

The  process  for  the  Verification  and  Validation  of  the  HEL  System  by  DSHEL  is 
shown  in  Eigure  85  which  was  adapted  from  the  System  Evaluation  and  corrective  action 
loop  (Blanchard  and  Eabrycky  2011).  This  process  included  a  feedback  loop  allowing  the 
information  collected  from  the  HEE  system  onboard  ship  to  provide  the  program  office 
and  stakeholder’s  data  which  would  eventually  inform  design  decisions  through 
sustainment. 
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The  process  began  under  the  assumption  that  most  data  would  be  collected  during 
either  test  activities  or  general  shipboard  operation  activities,  (indicated  by  rectangular 
process  blocks).  The  main  entity  for  collection  and  processing  of  this  information  would 
be  the  DSHEL  system  (indicated  by  the  trapezoid).  Many  of  the  collection  points  were 
discussed  in  the  previous  section  covering  the  physical  architecture  and  were  therefore 
not  discussed  here.  All  raw  HEL  system  data  (indicated  by  the  rhombus)  was  collected, 
formatted,  and  stored  in  the  onboard  DSHEE  database  (indicated  by  the  three 
dimensional  cylinder).  Once  the  information  was  stored,  through  a  combination  of 
automated  analysis  tools  and  user  analysis  tools  the  HEE  system  data  would  be  correlated 
with  on  shore  sustainment  databases  (indicated  by  the  two  dimensional  cylinder)  and 
analyzed  to  collect  higher  level  metrics  on  performance,  system  effectiveness,  and 
logistic  support  capability  (indicated  by  the  rectangular  sub  process  blocks  with  the  lines 
on  either  side). 

These  higher  level  metrics  are  to  be  forwarded  to  shore.  In  the  event  that  a 
problem  in  the  HEE  system  performance,  effectiveness,  or  logistic  support  capability  was 
detected,  all  relevant  information  related  to  the  problem  being  detected  is  sent  to  shore. 
Once  on  shore,  the  problem  is  analyzed  and  correlated  with  historical  information  for  the 
specific  HEE  baseline  as  well  as  other  HEE  baselines  currently  in  operation  within  the 
Elect.  If  historical  information  existed  related  to  the  observed  problem,  then  it  was  used 
in  conjunction  with  any  corrective  procedures  that  already  existed  to  resolve  the  issue. 
These  corrective  procedures  would,  in  many  cases,  fall  under  one  of  the  major  outputs 
from  the  previously  described  top  level  IDEEO  context  diagram. 

In  addition  to  the  corrective  action  being  taken  to  remedy  the  immediate  problem 
being  seen  on  the  specific  platform,  an  evaluation  of  whether  the  problem  was  systemic 
in  nature  should  be  accomplished.  If  a  determination  was  made  that  the  problem  was 
systemic  in  nature,  affecting  the  whole  baseline,  then  an  engineering  change  proposal 
(ECP)  would  be  developed. 

This  ECP  includes  an  analysis  of  alternatives  (AoA)  and  a  long  term  cost  analysis 

to  enable  the  program  office  (PO)  to  make  an  informed  decision  on  the  HEE  system 

design.  Any  changes  that  are  proposed  by  the  system  engineer  are  to  be  traced  back  to 
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system  requirements  that  are  not  being  met  as  a  result  of  the  eurrent  design.  If  the  ECP  is 
approved,  then  a  more  formal  ship  change  document  (SCD)  is  initiated.  An  SCD  is  the 
only  approved  path  for  implementation  of  a  change  on  a  fleet  ship.  The  SCD  process  will 
not  be  discussed  here;  however,  if  the  reader  wishes  to  understand  this  process  further, 
the  SCD  process  is  governed  under  the  Navy  Modernization  Process  -  Maintenance 
Operations  Manual  (NMP-MOM).  An  SCD  is  a  living  document  that  outlines  all  aspects 
of  a  system  that  might  be  affected  by  said  change.  This  includes,  not  only  a  description  of 
the  changes,  but  an  identification  of  all  logistical  impacts,  distributed  system  impacts,  a 
detailed  cost  benefit  analysis,  fielding  plan.  Applied  Figure  of  Merit  (AFOM),  as  well  as 
identification  of  any  testing  that  may  be  required  for  the  system  should  this  change  be 
approved. 

Once  the  SCD  had  been  initiated  and  approved  by  the  Fleet  for  installation  on 
hull,  the  information  would  be  fed  back  to  the  DSHEF  onboard  ship.  Updates  to  the 
analysis  portion  of  the  DSHEF  system  would  inform  the  user  of  the  long-term  corrective 
actions  in  place. 

The  verification  and  validation  feedback  loop  for  the  DSHEF  design  provided  a 
critical  component  to  the  sustainment  of  the  HEF  system  that  is  lacking  in  many  of  the 
fielded  systems  today.  Furthermore,  the  feedback  loop  aligns  to  existing  USN  procedures 
for  configuration  management  (CM)  and  ship  change  processes.  Any  analysis  done  by 
the  DSHEF  system  was  not  lost  rather  it  allowed  the  HEF  system  design  to  mature  over 
time  causing  the  system  to  become  more  reliable.  Ultimately,  this  would  allow  the 
stakeholders  for  the  HEF  system  to  realize  a  lower  life-cycle  total  ownership  cost. 

E.  SUMMARY 

This  chapter  discussed  several  important  factors  related  to  the  DSHEF  system. 
Building  on  the  stakeholder  needs  analysis  and  the  requirements  analysis  that  was 
discussed  in  Chapter  II  and  III  respectively,  this  chapter  provided  a  concept  definition 
and  design.  The  chapter  began  with  a  discussion  of  the  architectural  design  approach  that 
was  used  by  the  team.  This  included  a  discussion  of  the  functional  physical  and  allocated 
architecture  concepts.  The  chapter  went  into  the  actual  architecture  design  for  the 
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DSHEL  system.  Included  in  this  effort,  were  the  requirements  which  drove  the 
development  of  the  functional  IDEFO  diagrams  for  the  system,  proposed  system  sub¬ 
system  diagrams,  notional  major  interface  diagrams  between  DSHEE  and  HEE,  as  well 
as  the  DSHEE  and  the  shipboard  network.  The  T&E  methodology  for  the  DSHEE 
system,  as  well  as  the  verification  and  validation  process  for  DSHEE,  produced  findings 
which  would  inform  decisions  made  for  the  HEE  throughout  its  life  cycle. 
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V.  MODELING  AND  SIMULATION 


The  following  sections  detail  the  modeling  and  simulation  (M&S)  effort 
performed  to  analyze  the  models  of  DS:  Status  Quo  Distance  Support,  Integrated 
Distance  Support,  and  No  Distance  Support. 

The  purpose  of  M&S  is  to  quantify  and  gain  insight  into  the  effects  of  integrated 
DS  implementation.  The  primary  objective  for  M&S  was  to  establish  easy  to  understand, 
flexible  models  that  can  be  used  to  make  decisions  on  how  to  implement  DS.  A 
secondary  objective  was  to  enter  unbiased,  publically  releasable  values  and  distributions 
into  the  models  to  study  the  results.  The  final  objective  was  to  create  a  theoretical  “No 
Support”  model  to  show  the  effects  of  non-existent  DS  from  future  systems  and 
platforms. 

A,  MODELING  AND  SIMULATION  METHODOLOGY 

Two  complementary  methods  were  utilized  to  create  a  complete  picture  of  DS 
impact.  A  frequency  model  was  created  as  a  spreadsheet  to  assess  system  Ao  in  a  format 
that  is  commonly  reported.  The  second  method  utilized  a  modeling  and  simulation  tool  to 
go  beyond  a  single  number  result  and  explore  the  time-based  result  of  distance  support 
implantation. 

1,  Frequency  Modeling 

The  frequency  model  uses  spreadsheet  analysis,  as  is  commonly  performed  in 
annual  reviews  for  system  effectiveness.  The  analysis  seeks  to  determine  HEL  System 
Aq.  This  information  was  used  conjunction  with  maintenance  costs  to  make  an  effective 
AoA.  Strong  variation  in  administrative  delay  time  and  active  maintenance  time  are 
expected  between  models.  Benefits  of  this  method  include:  common  format  currently 
presented  to  decision  makers,  only  high-level  average  values  are  necessary  for  input,  and 
simple  calculations  determine  all  results.  The  primary  downside  of  this  analysis  is  that  a 
single  value  for  Ao  and  maintenance  times  is  produced.  Larger  data  sets  result  in  higher 
fidelity  of  decision  making,  whereas  a  single  value  is  limiting. 
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2,  Time  Modeling 

The  time  model  uses  M&S  tools  to  take  basic  values  and  answers  to  simple 
questions  to  determine  time-based  distributions.  The  analysis  method  also  seeks  to 
determine  HEL  Down  Time,  which  is  an  input  used  to  determining  Aq. 

B,  MODELING  AND  SIMULATION  TOOLS 

Two  software  tools  were  utilized  for  the  M&S  effort: 

•  Microsoft  Excel  2010 

•  Imagine  That  ExtendSim  Version  9. 1 

These  two  tools  were  utilized  due  to  their  familiarity  and  wide  spread  use  in 
industry  and  USN  academia. 

C.  MODEL  DESCRIPTION 

Three  models  were  created  for  the  M&S  effort:  Status  Quo  Distance  Support, 
Integrated  Distance  Support,  and  No  Distance  Support.  Below,  each  of  these  models  is 
explained  through  in-depth  analysis. 

1,  Status  Quo  Distance  Support 

The  Status  Quo  Distance  Support  Model  is  based  on  level  of  repair  analysis 
(LORA)  currently  implemented  on  most  USN  platforms.  A  basic  depiction  of  the  process 
can  be  seen  in  Eigure  86  where  many  problems  are  encountered  at  the  Organizational 
Level.  Some  are  resolved  and  the  rest  are  passed  to  the  next  level  of  repair,  and  so  forth. 
The  Status  Quo  Model  depicts  a  multi-stage  support  model.  There  are  four  levels  of 
support:  Organizational  Level  Repair,  Intermediate  Level  Repair,  ISEA  Level  Repair, 
and  Liyaway  Repair.  Eigure  87  details  the  model  logic  and  functional  flow  decision 
process  which  governs  the  simulation.  In  the  model  decision  flow  diagram,  rectangles 
represent  processes  which  cause  time  expenditures  and  diamonds  represent  decision 
points  or  path  selection. 
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The  DSHEL  -  Status  Quo  Model  Decisional  Flow  Diagram  shows  the  decision 
path  for  system  issue  resolution  in  its  current  state.  It  represents  a  multi-tier  level  of 
support  structure  as  described  in  DODD  4151.18  (United  States  Department  of  Defense 
2004): 


•  Organizational-Level  Maintenance.  Maintenance  normally  performed  by  an 
operating  unit  on  a  day-to-day  basis  in  support  of  its  own  operations.  The 
organizational-level  maintenance  mission  is  to  maintain  assigned  equipment 
in  a  full  mission-capable  status  while  continually  improving  the  process. 
Organizational-level  maintenance  can  be  grouped  under  categories  of 
“inspections,”  “servicing,”  “handling,”  and  “preventive  maintenance.” 

•  Intermediate-Level  Maintenance.  That  materiel  maintenance  that  is  the 
responsibility  of,  and  performed  by,  designated  maintenance  activities  in 
support  of  using  organizations.  The  intermediate-level  maintenance  mission  is 
to  enhance  and  sustain  the  combat  readiness  and  mission  capability  of 
supported  activities  by  providing  quality  and  timely  materiel  support  at  the 
nearest  location  with  the  lowest  practical  resource  expenditure.  Intermediate- 
level  maintenance  includes  limited  repair  of  commodity-orientated 
components  and  end  items,  job  shop,  bay,  and  production  line  operations  for 
special  mission  requirements;  repair  of  printed  circuit  boards,  software 
maintenance,  and  fabrication  or  manufacture  of  repair  parts;  assemblies, 
components,  and  jigs  and  fixtures,  when  approved  by  higher  levels. 

•  Depot  Maintenance.  That  materiel  maintenance  requiring  major  overhaul  or  a 
complete  rebuilding  of  parts,  assemblies,  subassemblies,  and  end  items, 
including  the  manufacture  of  parts,  modifications,  testing,  and  reclamation  as 
required.  Depot  maintenance  serves  to  support  lower  categories  of 
maintenance  by  providing  technical  assistance  and  performing  that 
maintenance  beyond  their  responsibility.  Depot  maintenance  provides  stocks 
of  serviceable  equipment  because  it  has  available  more  extensive  facilities  for 
repair  than  are  available  in  lower  maintenance  activities.  Depot  maintenance 
includes  all  aspects  of  software  maintenance. 

In  the  decisional  flow  model,  the  sailor  represents  the  Organizational-Level 
Maintenance.  The  sailor  recognizes  the  failure  and  performs  diagnostics  on  the  system.  If 
it  is  within  the  sailor’s  ability,  he  will  attempt  repair  of  the  system.  If  the  sailor  feels  the 
problem  is  beyond  their  ability,  the  problem  is  immediately  elevated  to  the  RMC.  If 
repair  is  attempted  by  the  sailor,  it  is  assessed  if  a  part  is  needed.  It  will  next  be  necessary 
to  determine  whether  or  not  the  part  is  available  onboard.  If  not  onboard,  the  part  must  be 
ordered  through  the  supply  system  and  delivered  to  the  ship.  If  all  required  materials  are 
present  (a  part  is  not  needed,  a  part  is  needed  but  onboard,  or  a  part  is  ordered  and 
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received),  then  the  repair  attempt  is  made  on  the  system  and  operationally  tested.  Upon 
completion  of  the  operational  test,  the  system  is  assessed  as  fixed  or  not  fixed.  If  the 
problem  is  fixed,  then  the  flow  ends  with  a  resolved  issue.  If  the  issue  is  assessed  as  not 
fixed,  the  sailor  may  or  may  not  re-attempt  repair  of  the  issue.  If  re-attempt  is  decided, 
sailor  diagnostics  is  repeated.  If  re-attempt  is  considered  beyond  the  ability  of  the  sailor, 
then  the  issue  is  elevated  to  the  RMC. 

In  the  decisional  flow  model,  the  RMC  represents  the  Intermediate-Level 
Maintenance  as  it  relates  to  DODD  4151.18.  The  RMC  receives  failure  notification  and 
performs  diagnostics  on  the  system.  If  it  is  within  the  RMC’s  resources  and  abilities,  it 
will  attempt  to  repair  the  system.  If  the  RMC  feels  the  problem  is  beyond  its  resources  or 
abilities,  the  problem  is  immediately  elevated  to  the  ISEA.  If  repair  is  attempted  by  the 
RMC,  it  is  assessed  if  a  part  is  needed.  It  will  next  be  necessary  to  determine  whether  or 
not  the  part  is  available  onboard.  If  not  onboard,  the  part  must  be  ordered  through  the 
supply  system  and  delivered  to  the  ship.  If  all  required  materials  are  present  (a  part  is  not 
needed,  a  part  is  needed  but  onboard,  or  a  part  is  ordered  and  received),  then  the  repair 
attempt  is  made  on  the  system  and  operationally  tested.  Upon  completion  of  the 
operational  test,  the  system  is  assessed  as  fixed  or  not  fixed.  If  the  problem  is  fixed  then 
the  flow  ends  with  a  resolved  issue.  If  the  issue  is  assessed  as  not  fixed,  the  RMC  may  or 
may  not  re-attempt  repair  of  the  issue.  If  re-attempt  is  decided,  RMC  diagnostics  is 
restarted.  If  re-attempt  is  considered  beyond  the  ability  of  the  RMC,  then  the  issue  is 
elevated  to  the  ISEA. 

In  the  decisional  flow  model,  the  ISEA  represents  a  second  level  of  the 
Intermediate-Eevel  Maintenance.  The  ISEA  receives  a  failure  notification  and  performs 
diagnostics  on  the  system.  If  it  is  within  the  ISEA’s  DS  ability,  it  will  attempt  repair  of 
the  system.  If  the  ISEA  feels  the  problem  is  beyond  repair  through  DS,  the  problem  is 
immediately  elevated  to  onboard  support,  referred  to  as  a  Elyaway  Team.  It  consists  of 
the  same  members  as  the  ISEA  but  is  specific  to  hands-on  the  system.  If  repair  is 
attempted  by  the  ISEA,  it  is  assessed  if  a  part  is  needed.  It  will  next  be  necessary  to 
determine  whether  or  not  the  part  is  available  onboard.  If  not  onboard,  the  part  must  be 
ordered  through  the  supply  system  or  borrowed  from  resources  available  to  the  ISEA, 
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such  as  from  test  sites,  borrowed  from  other  assets  not  eurrently  in  need  of  them,  sueh  as 
those  in  refurbishment,  high-value  spares,  or  loaned  from  produetion  material,  and 
delivered  to  the  ship.  If  all  required  materials  are  present  (a  part  is  not  needed,  a  part  is 
needed  but  onboard,  or  a  part  is  ordered  and  received),  then  the  repair  attempt  is  made  on 
the  system  and  operationally  tested.  Upon  completion  of  the  operational  test,  the  system 
is  assessed  as  fixed  or  not  fixed.  If  the  problem  is  fixed  then  the  flow  ends  with  a 
resolved  issue.  If  the  issue  is  assessed  as  not  fixed,  the  ISEA  may  or  may  not  re-attempt 
repair  of  the  issue  remotely.  If  re-attempt  is  deeided,  ISEA  remote  diagnostics  is  begun 
again.  If  re-attempt  is  eonsidered  beyond  the  capability  of  affective  DS,  then  the  issue  is 
elevated  to  the  Elyaway  Team. 

The  Elyaway  Team  represents  the  third  level  of  the  Intermediate-Eevel 
Maintenance  and  the  final  level  of  eurrent  DS.  Depot  Maintenance  is  not  present  for 
corrective  maintenance  in  most  current  systems.  If  information  is  needed  from  the 
manufacturer,  it  is  the  ISEA’s  responsibility  to  aequire  that  information.  Eor  that  reason. 
Depot  Maintenance  is  not  included  in  the  Status  Quo  Distance  Support  flow  ehart.  The 
flyaway  team  beeomes  aware  of  the  problem  through  its  own  organization  (the  ISEA) 
and  travels  to  the  ship.  The  Elyaway  Team  performs  diagnostics  on  the  system.  It  is 
assessed  if  a  part  is  needed.  It  will  next  be  neeessary  to  determine  whether  or  not  the  part 
is  available  onboard.  If  not  onboard,  the  part  must  be  ordered  through  the  supply  system 
or  borrowed  from  resources  available  to  the  ISEA  and  delivered  to  the  ship.  If  all 
required  materials  are  present  (a  part  is  not  needed,  a  part  is  needed  but  onboard,  or  a  part 
is  ordered  and  reeeived),  then  the  repair  attempt  is  made  on  the  system  and  operationally 
tested.  Upon  eompletion  of  the  operational  test,  the  system  is  assessed  as  fixed  or  not 
fixed.  If  the  problem  is  fixed  then  the  flow  ends  with  a  resolved  issue.  If  the  issue  is 
assessed  as  not  fixed,  the  flyaway  team  must  re-attempt  repair  until  the  issue  is  resolved. 
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Figure  88.  DSHEL — Status  Quo  Model 
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a. 


Organizational  Level  Repair 


Organizational  repair,  as  applied  to  USN  DS  and  this  model,  refers  to  “Sailor” 
actions.  The  sailor  is  expected  to  follow  a  process  to  diagnose  and  attempt  repair  of  the 
failed  system  to  the  best  of  his  abilities.  This  procedure  is  the  same  for  nearly  every 
element  of  every  combat  system  aboard  ships.  The  sailor  receives  notification  of  the  fault 
through  automated  monitoring  of  the  system  and  daily  operational  tests.  Diagnostics  of 
the  fault  is  then  attempted  using  BIT  and  technical  manuals.  Depending  on  the  training  of 
the  sailor,  the  severity  of  the  apparent  fault,  and  the  resources  available  to  attempt  repair, 
the  sailor  can  either  attempt  repair  or  defer  the  fault  to  the  next  level,  which  is  the  RMC. 
If  repair  is  attempted  at  the  organizational  level,  a  part  may  or  may  not  be  needed;  if  it  is 
needed,  the  part  may  or  may  not  be  onboard.  If  a  part  if  needed  and  not  onboard,  it  must 
be  ordered  through  the  supply  system.  After  ordering,  the  part  must  be  delivered  to  the 
ship.  After  receipt  of  the  part,  either  through  onboard  spares  or  through  the  supply 
system,  the  part  needs  to  be  installed  and  operationally  tested.  After  testing,  the  problem 
is  either  corrected  or  not.  If  the  problem  has  not  been  corrected,  the  sailor  may  or  may  not 
re-attempt  repair.  If  re-attempt  is  desired,  re-diagnostics  of  the  system  is  restarted.  If  re¬ 
attempt  of  repair  is  not  sought,  the  problem  is  deferred  to  the  next  level  of  support. 

b.  Intermediate  Level  Repair 

Intermediate  repair,  as  applied  to  USN  DS  and  this  model,  refers  to  RMC  actions. 
The  RMC  follows  a  process  to  diagnose  and  attempt  repair  of  the  failed  system  to  the 
best  of  its  abilities.  This  procedure  is  the  same  for  nearly  every  element  of  every  combat 
system  aboard  ships.  The  RMC  receives  notification  of  the  fault  from  the  sailor  by 
traditional  methods  such  as  phone  and  email.  Diagnostics  of  the  fault  is  then  attempted 
using  data  provided  from  the  sailor  and  technical  manuals  as  well  as  lessons  learned  from 
repairing  systems  on  other  platforms.  Depending  on  the  severity  of  the  apparent  fault,  and 
the  resources  available  to  attempt  repair,  the  RMC  can  either  attempt  repair  or  defer  the 
fault  to  the  next  level,  which  is  the  ISEA.  If  repair  is  attempted  at  the  Intermediate  Level, 
a  part  may  or  may  not  be  needed;  if  it  is  needed,  the  part  may  or  may  not  be  onboard.  If  a 
part  if  needed  and  not  onboard,  it  must  be  ordered  through  the  supply  system.  After 
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ordering,  the  part  must  be  delivered  to  the  ship.  After  reeeipt  of  the  part,  either  through 
onboard  spares  or  through  the  supply  system,  the  part  needs  to  be  installed  and 
operationally  tested.  After  testing,  the  problem  is  either  eorreeted  or  not.  If  the  problem 
has  not  been  eorreeted,  the  RMC  may  or  may  not  re-attempt  repair.  If  re-attempt  is 
desired,  re-diagnostics  of  the  system  is  restarted.  If  re-attempt  of  repair  is  not  sought,  the 
problem  is  deferred  to  the  next  level  of  support. 

c.  ISEA  Level  Repair 

ISEA  Repair,  as  applied  to  USN  DS  and  this  model,  refers  to  ISEA  actions. 
Traditionally,  depot  maintenance  is  required  after  Intermediate  Eevel  Repair  has  failed  or 
been  deferred.  However,  because  most  ship  systems  cannot  easily  be  removed  and 
transported,  the  ISEA  serves  as  the  last  two  levels  of  repair  for  USN  DS.  In  addition  to 
having  the  maximum  system  documentation  available  for  fault  analysis,  the  ISEA  has  a 
direct  relationship  with  the  system  manufacturer.  The  ISEA  also  witnesses  and 
documents  the  most  difficult  system  repairs  across  all  platforms  of  which  the  system  is 
installed. 

The  ISEA  follows  a  process  to  diagnose  and  attempt  repair  of  the  failed  system  to 
the  best  of  its  abilities.  This  procedure  is  the  same  for  nearly  every  element  of  every 
combat  system  aboard  ships.  The  ISEA  receives  notification  of  the  fault  from  both  the 
RMC  and  Sailor  by  traditional  methods  such  as  phone  and  email.  Diagnostics  of  the  fault 
is  then  attempted  using  data  provided  from  the  sailor  and  technical  manuals  as  well  as 
lessons  learned  from  repairing  systems  on  other  platforms.  Depending  on  the  severity  of 
the  apparent  fault,  and  the  resources  available  to  attempt  repair,  the  ISEA  can  either 
attempt  repair  or  defer  the  fault  to  the  next  level,  which  is  Elyaway  Support.  The  support 
is  performed  by  the  ISEA  in  both  cases.  However,  if  enough  information  cannot  be 
gleaned  by  remote  reporting  means,  engineers  and  technicians  from  the  ISEA  may  elect 
to  travel  to  the  ship  for  repair.  Remote  repair  is  attempted  first  in  all  but  the  most  extreme 
cases.  If  repair  is  attempted  at  the  ISEA  Eevel,  a  part  may  or  may  not  be  needed;  if  it  is 
needed,  the  part  may  or  may  not  be  onboard.  If  a  part  if  needed  and  not  onboard,  it  must 
be  ordered  through  the  supply  system.  However,  the  ISEA  has  several  resources  that  all 
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other  entities  do  not.  The  ISEA,  at  its  discretion,  may  scavenge  parts  from  test  systems  or 
engineering  models,  loan  parts  from  accumulated  high-value  spares,  loan  parts  from 
future  install  allocations,  and  in  extreme  cases,  borrow  parts  from  the  manufacturer.  After 
ordering  or  scavenging,,  the  part  must  be  delivered  to  the  ship.  The  ISEA  has  at  its 
discretion,  overnight  shipping.  After  receipt  of  the  part,  either  through  onboard  spares  or 
through  the  supply  system,  the  part  needs  to  be  installed  and  operationally  tested.  After 
testing,  the  problem  is  either  corrected  or  not.  If  the  problem  has  not  been  corrected,  the 
ISEA  may  or  may  not  re-attempt  repair  by  remote  support.  If  re-attempt  is  desired,  re¬ 
diagnostics  of  the  system  is  begun.  If  re-attempt  of  repair  is  not  sought,  the  problem  is 
deferred  to  the  next  level  of  support  which  is  flyaway  support  by  the  ISEA. 

d.  Flyaway  Repair 

Elyaway  Repair,  as  applied  to  USN  DS  and  this  model,  refers  to  ISEA  actions  as 
performed  aboard  ship.  Traditionally,  depot  maintenance  is  required  as  the  last  level  of 
repair  when  prior  repair  has  failed  or  been  deferred.  However,  because  most  ship  systems 
cannot  easily  be  removed  and  transported,  the  ISEA  serves  as  the  last  two  levels  of  repair 
for  USN  DS.  In  addition  to  having  the  maximum  system  documentation  available  for 
fault  analysis,  the  ISEA  has  a  direct  relationship  with  the  system  manufacturer.  The  ISEA 
also  witnesses  and  documents  the  most  difficult  system  repairs  across  all  platforms  of 
which  the  system  is  installed.  The  ISEA  can  perform  diagnostics  with  greater  ease,  speed, 
and  accuracy  than  guiding  a  sailor  in  the  actions.  The  ISEA  also  has  specialized  tools 
available  to  make  diagnostics  and  repairs. 

The  ISEA  flyaway  team  follows  a  process  to  diagnose  and  attempt  repair  of  the 
failed  system  to  the  best  of  its  abilities.  This  procedure  is  the  same  for  nearly  every 
element  of  every  combat  system  aboard  ships.  The  ISEA  travels  to  the  platform 
containing  the  system  requiring  repair.  Diagnostics  of  the  fault  is  then  attempted  using 
BIT  and  technical  manuals  as  well  as  lessons  learned  from  repairing  systems  on  other 
platforms.  All  tests  previously  performed  are  re-run  with  new  instrumentation.  The  ISEA 
must  attempt  repair  and  remain  onboard  until  the  problem  is  resolved.  After  diagnostics, 
a  part  may  or  may  not  be  needed;  if  it  is  needed,  the  part  may  or  may  not  be  onboard.  If  a 
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part  if  needed  and  not  onboard,  it  must  be  ordered  through  the  supply  system.  However, 
the  ISEA  has  several  resourees  that  all  other  entities  do  not.  The  ISEA,  at  its  diseretion, 
may  seavenge  parts  from  test  systems  or  engineering  models,  loan  parts  from 
aeeumulated  high-value  spares,  loan  parts  from  future  install  alloeations,  and  in  extreme 
eases,  borrow  parts  from  the  manufaeturer.  After  ordering  or  seavenging,  the  part  must  be 
delivered  to  the  ship.  The  ISEA  has  at  its  diseretion,  overnight  shipping.  After  reeeipt  of 
the  part,  either  through  onboard  spares  or  through  the  supply  system,  the  part  needs  to  be 
installed  and  operationally  tested.  After  testing,  the  problem  is  either  eorreeted  or  not.  If 
the  problem  has  not  been  eorreeted,  the  ISEA  re-attempts  repair  until  the  problem  is 
resolved. 

2,  Integrated  Distance  Support 

The  Integrated  Distanee  Support  Model  represents  the  model  that  is  proposed  in 
the  CONOPS  of  this  effort.  The  model  depiets  a  two-stage  support  model  involving 
distanee  support  level  repair  and  flyaway  repair.  Eigure  89  details  the  model  logie  and 
funetional  flow  deeision  proeess  whieh  governs  the  simulation. 
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Figure  89.  DSHEL  -  Integrated  Distance  Support  Model  Decisional  Flow 


►  Issue  Resolved 
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The  DSHEL — Integrated  Distance  Support  Model  Decisional  Flow  Diagram 
shows  the  decision  path  for  system  issue  resolution  in  a  theoretical  future  state  as 
proposed  by  this  effort.  It  represents  a  two-tier  level  of  support  structure  that  is  an 
integration  and  evolution  of  the  levels  of  support  described  in  DODD  4151.18  (United 
States  Department  of  Defense  2004).  A  basic  depiction  of  the  process  can  be  seen  in 
Figure  89  where  many  problems  are  encountered  at  the  distance  support  level  repair. 
Most  are  resolved  and  the  rest  are  passed  to  the  flyaway  repair 

In  the  decisional  flow  model,  as  compared  to  the  Status  Quo  Model  Decisional 
Flow  Diagram,  DS  represents  both  the  organizational-level  maintenance  and  the  first  two 
levels  of  intermediate-level  maintenance.  The  sailor  recognizes  the  failure  and  connects 
with  DS  to  perform  diagnostics  on  the  system.  Remote  diagnostics  are  conducted  on  the 
system  and  it  is  assessed  if  a  part  is  needed.  It  will  next  be  necessary  to  determine 
whether  or  not  the  part  is  available  onboard.  If  not  onboard,  the  part  must  be  ordered 
through  the  supply  system  or  borrowed  from  resources  available  to  the  ISFA  and 
delivered  to  the  ship.  If  all  required  materials  are  present  (a  part  is  not  needed,  a  part  is 
needed  but  onboard,  or  a  part  is  ordered  and  received),  then  the  repair  attempt  is  made  on 
the  system  and  operationally  tested.  Upon  completion  of  the  operational  test,  the  system 
is  assessed  as  fixed  or  not  fixed.  If  the  problem  is  fixed  then  the  flow  ends  with  a 
resolved  issue.  If  the  issue  is  assessed  as  not  fixed,  the  DS  team  may  or  may  not  re¬ 
attempt  repair  of  the  issue.  If  re-attempt  is  decided,  DS  diagnostics  are  restarted.  If  re¬ 
attempt  is  considered  beyond  the  ability  of  DS,  then  the  issue  is  elevated  to  the  flyaway 
team. 

The  flyaway  team  represents  the  second  and  the  final  level  of  integrated  distance 
support.  Depot  maintenance  is  not  present  for  corrective  maintenance  in  most  current 
systems.  If  information  is  needed  from  the  manufacturer,  it  is  the  ISFA’s  responsibility  to 
acquire  that  information.  For  that  reason,  depot  maintenance  is  not  included  in  the  Status 
Quo  Distance  Support  flow  chart.  The  flyaway  team  becomes  aware  of  the  problem 
though  its  own  organization  (the  DS  team)  and  travels  to  the  ship.  The  flyaway  team 
performs  diagnostics  on  the  system.  It  is  assessed  if  a  part  is  needed.  It  will  next  be 
necessary  to  determine  whether  or  not  the  part  is  available  onboard.  If  not  onboard,  the 
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part  must  be  ordered  through  the  supply  system  or  borrowed  from  resourees  available  to 
the  ISEA  and  delivered  to  the  ship.  If  all  required  materials  are  present  (a  part  is  not 
needed,  a  part  is  needed  but  onboard,  or  a  part  is  ordered  and  reeeived),  then  the  repair 
attempt  is  made  on  the  system  and  operationally  tested.  Upon  eompletion  of  the 
operational  test,  the  system  is  assessed  as  fixed  or  not  fixed.  If  the  problem  is  fixed  then 
the  flow  ends  with  a  resolved  issue.  If  the  issue  is  assessed  as  not  fixed,  the  flyaway  team 
must  re-attempt  repair  until  the  issue  is  resolved. 
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DHELL  •  Integrated  Support 


Figure  90.  DSHEL  -  Integrated  Distance  Support  Model 
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a.  Distance  Support  Level  Repair 

Distance  Support  Repair,  as  applied  to  USN  DS  and  this  model  is  referred  to  in 
terms  of  sailor,  RMC,  and  ISEA  actions  performed  concurrently.  The  DS  elements  follow 
a  process  to  diagnose  and  attempt  repair  of  the  failed  system  to  the  best  of  its  abilities. 
This  proeedure  is  theoretieal  but  is  designed  for  nearly  every  element  of  every  combat 
system  aboard  ships.  The  ISEA  receives  notifieation  of  the  fault  by  an  automated  system, 
soon  after  the  fault  is  detected  onboard.  Details  of  the  fault  and  self-tests,  as  well  as 
historieal  system  health  becomes  available  on  a  secure  server  for  analysis.  Secure  ehat  is 
established  with  the  ship  if  the  shore-side  support  is  not  notified  that  the  fault  is 
inadvertent,  such  as  due  to  power  loss  or  cyeling  the  system.  Assuming  the  fault  deteeted 
is  a  true  fault,  diagnosties  of  the  fault  is  then  attempted  using  data  provided  from  the 
system,  sailor,  automated  fault  lookup,  and  teehnical  manuals  as  well  as  lessons  learned 
from  repairing  systems  on  other  platforms.  The  CONOPS  for  this  methodology  requires 
that  remote  support  always  be  attempted  before  the  only  other  level  of  support,  whieh  is 
flyaway  support.  Diagnostics  are  performed  between  all  parties  on  the  integrated  support 
system.  A  part  may  or  may  not  be  needed;  if  it  is  needed,  the  part  may  or  may  not  be 
onboard.  If  a  part  is  needed  and  not  onboard,  it  must  be  ordered  through  the  supply 
system.  However,  the  ISEA  has  several  resources  that  all  other  entities  do  not.  The  ISEA, 
at  its  discretion,  may  seavenge  parts  from  test  systems  or  engineering  models,  loan  parts 
from  aecumulated  high-value  spares,  loan  parts  from  future  install  alloeations,  and  in 
extreme  cases,  borrow  parts  from  the  manufacturer.  After  ordering  or  seavenging,  the 
part  must  be  delivered  to  the  ship.  The  ISEA  has  at  its  diseretion,  overnight  shipping. 
After  receipt  of  the  part,  either  through  onboard  spares  or  through  the  supply  system,  the 
part  needs  to  be  installed  and  operationally  tested.  Testing  is  performed  with  the  DS 
system  reporting  results  back  to  the  integrated  support  team,  after  testing  the  problem  is 
either  corrected  or  not.  If  the  problem  has  not  been  eorrected,  re-attempt  of  repair  by 
remote  support  will  almost  always  be  attempted.  If  re-attempt  is  desired,  re-diagnosties  of 
the  system  is  restarted.  If  re-attempt  of  repair  is  not  sought,  the  problem  is  deferred  to  the 
next  level  of  support  which  is  flyaway  team  support  by  the  ISEA. 
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b.  Flyaway  Repair 


Flyaway  Repair,  as  applied  to  USN  DS  and  this  model,  refers  to  ISEA  aetions,  as 
performed  aboard  ship.  Traditionally,  depot  maintenance  is  required  as  the  last  level  of 
repair  if  previous  repair  attempts  have  failed  or  been  deferred.  However,  because  most 
ship  systems  cannot  easily  be  removed  and  transported,  the  ISEA  serves  as  the  last  level 
of  repair  for  USN  DS.  In  addition  to  having  the  maximum  system  documentation 
available  for  fault  analysis,  the  ISEA  has  a  direct  relationship  with  the  system 
manufacturer.  The  ISEA  also  witnesses  and  documents  the  most  difficult  system  repairs 
across  all  platforms  that  the  system  is  installed  on.  The  ISEA  can  perform  diagnostics 
with  greater  ease,  speed,  and  accuracy  than  guiding  a  sailor  in  the  actions.  The  ISEA  also 
has  specialized  tools  available  to  make  diagnostics  and  repairs. 

The  ISEA  flyaway  team  follows  a  process  to  diagnose  and  attempt  repair  of  the 
failed  system  to  the  best  of  its  abilities.  This  procedure  is  the  same  for  nearly  every 
element  of  every  combat  system  aboard  ships.  The  ISEA  travels  to  the  platform 
containing  the  system  requiring  repair.  Diagnostics  of  the  fault  is  then  attempted  using 
BIT  and  technical  manuals  as  well  as  lessons  learned  from  repairing  systems  on  other 
platforms.  All  tests  previously  performed  are  re-run  with  new  instrumentation.  The  ISEA 
must  attempt  repair  and  remain  onboard  until  the  problem  is  resolved.  After  diagnostics, 
a  part  may  or  may  not  be  needed;  if  it  is  needed,  the  part  may  or  may  not  be  onboard.  If  a 
part  if  needed  and  not  onboard,  it  must  be  ordered  through  the  supply  system.  However, 
the  ISEA  has  several  resources  that  all  other  entities  do  not.  The  ISEA,  at  its  discretion, 
may  scavenge  parts  from  test  systems  or  engineering  models,  loan  parts  from 
accumulated  high-value  spares,  loan  parts  from  future  install  allocations,  and  in  extreme 
cases,  borrow  parts  from  the  manufacturer.  After  ordering  or  scavenging,  the  part  must  be 
delivered  to  the  ship.  The  ISEA  has  at  its  discretion,  overnight  shipping.  After  receipt  of 
the  part,  either  through  onboard  spares  or  through  the  supply  system,  the  part  needs  to  be 
installed  and  operationally  tested.  After  testing,  the  problem  is  either  corrected  or  not.  If 
the  problem  has  not  been  corrected,  the  ISEA  re-attempts  repair  until  the  problem  is 
resolved. 
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3,  No  Distance  Support 

The  No  Distance  Support  Model  is  a  two  level  support  model  that  consists  only  of 
sailor  actions  and  contractor,  in-port  support.  The  model  depicts  a  two-stage  support 
model  involving  organizational  level  repair  and  contractor  repair.  Figure  92  details  the 
model  logic  and  functional  flow  decision  process  which  governs  the  simulation.  A  basic 
depiction  of  the  process  can  be  seen  in  Figure  91  where  many  problems  are  encountered 
at  the  Organizational  Level.  Some  are  resolved,  but  most  are  passed  to  the  next  level  of 
repair,  to  be  performed  by  a  contractor,  when  the  ship  is  in  port.  The  actual  ExtendSim 
model  used  for  simulation  is  shown  as  Figure  93. 


i  JJ 

Organizational 

Repair  ^ 


i  I  i 
i  i 


Contractor  Repair 


Figure  91.  Levels  of  Repair — No  Distance  Support 
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Figure  92  shows  the  decision  path  for  system  issue  resolution  in  a  theoretical 
current  state  in  which  DS  is  eliminated.  It  represents  a  major  departure  from  the  multi-tier 
level  of  support  structure  as  described  in  DODD  4151.18.  Instead  it  relies  on  only 
organizational-level  maintenance  and  depot  maintenance. 

In  the  decisional  flow  model,  the  sailor  represents  the  organizational-level 
maintenance.  The  sailor  recognizes  the  failure  and  performs  diagnostics  on  the  system.  If 
it  is  within  the  sailor’s  ability,  he  will  attempt  repair  of  the  system.  If  the  sailor  exercises 
all  known  tech  manual  procedures  assigned  to  their  level  of  maintenance  and  the  problem 
still  exists,  it  is  then  elevated  to  contractor  support  and  the  system  is  left  broken  until  the 
ship  returns  to  port.  If  repair  is  attempted  by  the  sailor,  it  is  assessed  if  a  part  is  needed.  It 
will  next  be  necessary  to  determine  whether  or  not  the  part  is  available  onboard.  If  not 
onboard,  the  part  must  be  ordered  through  the  supply  system  and  delivered  to  the  ship.  If 
all  required  materials  are  present  (a  part  is  not  needed,  a  part  is  needed  but  onboard,  or  a 
part  is  ordered  and  received),  then  the  repair  attempt  is  made  on  the  system  and 
operationally  tested.  Upon  completion  of  the  operational  test,  the  system  is  assessed  as 
fixed  or  not  fixed.  If  the  problem  is  fixed  then  the  flow  ends  with  a  resolved  issue.  If  the 
issue  is  assessed  as  not  fixed,  the  sailor  may  or  may  not  re-attempt  repair  of  the  issue.  If 
re-attempt  is  decided,  sailor  diagnostics  is  restarted.  If  re-attempt  is  considered  beyond 
the  ability  of  the  sailor,  then  the  issue  is  elevated  to  contractor  support. 

In  relation  to  DODD  4151.18,  in  the  decisional  flow  model,  the  contractor 

represents  the  depot  maintenance.  The  contractor  receives  a  failure  notification  from  the 

sailor  and  meets  the  ship  when  it  returns  to  port.  The  contractor  performs  diagnostics  on 

the  system.  It  is  assessed  if  a  part  is  needed.  It  will  next  be  necessary  to  determine 

whether  or  not  the  part  is  available  onboard.  If  not  onboard,  the  part  must  be  ordered 

through  the  supply  system  or  borrowed  from  resources  available  to  the  contractor  and 

delivered  to  the  ship.  If  all  required  materials  are  present  (a  part  is  not  needed,  a  part  is 

needed  but  onboard,  or  a  part  is  ordered  and  received),  then  the  repair  attempt  is  made  on 

the  system  and  operationally  tested.  Upon  completion  of  the  operational  test,  the  system 

is  assessed  as  fixed  or  not  fixed.  If  the  problem  is  fixed  then  the  flow  ends  with  a 

resolved  issue.  If  the  issue  is  assessed  as  not  fixed,  the  contractor  must  re-attempt  repair 
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until  the  issue  is  resolved.  The  ExtendSim  model  used  for  simulation  is  shown  as  Figure 
93 
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Figure  93.  DSHEL — ^No  Distance  Support  Model 
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a. 


Organizational  Level  Repair 


Organizational  Repair,  as  applied  to  USN  DS  and  this  model  is  referred  to  in 
terms  of  “Sailor”  actions.  The  sailor  is  expected  to  follow  a  process  to  diagnose  and 
attempt  repair  of  the  failed  system  to  the  best  of  his  or  her  abilities.  This  procedure  is  the 
same  for  nearly  every  element  of  every  combat  system  aboard  ships.  The  sailor  receives 
notification  of  the  fault  through  automated  monitoring  of  the  system  and  daily  operational 
tests.  Diagnostics  of  the  fault  is  then  attempted  using  BIT  and  technical  manuals. 
Depending  on  the  training  of  the  sailor,  the  severity  of  the  apparent  fault,  and  the 
resources  available  to  attempt  repair,  the  sailor  can  either  attempt  repair  or  defer  the  fault 
to  the  next  level.  If  repair  is  attempted  at  the  organizational  level,  a  part  may  or  may  not 
be  needed;  if  it  is  needed,  the  part  may  or  may  not  be  onboard.  If  a  part  if  needed  and  not 
onboard,  it  must  be  ordered  through  the  supply  system.  After  ordering,  the  part  must  be 
delivered  to  the  ship.  After  receipt  of  the  part,  either  through  onboard  spares  or  through 
the  supply  system,  the  part  needs  to  be  installed  and  operationally  tested.  After  testing, 
the  problem  is  either  corrected  or  not.  If  the  problem  has  not  been  corrected,  the  sailor 
may  or  may  not  re-attempt  repair.  If  re-attempt  is  desired,  re-diagnostics  of  the  system  is 
restarted.  If  re-attempt  of  repair  is  not  sought,  the  problem  is  deferred  to  the  next  level  of 
support. 

b.  Contractor  Repair 

Contractor  repair,  as  applied  to  USN  DS  and  this  model  is  referred  to  in  terms  of 
contractor  actions,  as  performed  aboard  ship,  in  port.  Traditionally,  depot  maintenance  is 
required  as  the  last  level  of  repair  has  failed  or  been  deferred.  However,  the  No  Support 
distance  support  model  requires  the  manufacturer  representatives  to  travel  to  the  ship  to 
diagnose  and  repair  systems  as  the  only  level  of  support  available  after  organizational 
level  repair  efforts. 

The  contractor  team  follows  a  process  to  diagnose  and  attempt  repair  of  the  failed 

system  to  the  best  of  its  abilities.  This  procedure  is  theoretical  and  is  modeled  to  be 

generally  applied.  While  content  would  be  varying  depending  on  the  manufacturer  and 

combat  system  element,  the  procedure  should  be  delivered  within  the  specification 
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written  in  the  eontraet  deliverables.  It  is  assumed  that  the  eontraetor  travels  to  the 
platform  eontaining  the  system  requiring  repair  in  order  to  meet  the  ship  upon  arrival  in 
port.  Diagnostics  of  the  fault  is  then  attempted  using  BIT  and  technical  manuals  as  well 
as  lessons  learned  from  repairing  systems  on  other  platforms.  After  diagnostics,  a  part 
may  or  may  not  be  needed;  if  it  is  needed,  the  part  may  or  may  not  be  onboard.  If  a  part  is 
needed  and  not  onboard,  it  must  be  ordered  through  the  supply  system.  However,  the 
contractor  has  several  resources  that  all  other  entities  do  not.  The  contractor  may 
scavenge  parts  from  engineering  models,  loan  parts  from  future  install  allocations,  and  in 
extreme  cases,  manufacturer  new  parts.  After  ordering  or  scavenging,  the  part  must  be 
delivered  to  the  ship.  The  contractor  has  at  its  discretion,  overnight  shipping.  However, 
systems  supported  in  this  manner  may  not  have  parts  available  in-country  and  are  likely 
subject  to  contracting  activities  to  provide  the  parts.  After  receipt  of  the  part,  either 
through  onboard  spares  or  through  the  supply  system,  the  part  needs  to  be  installed  and 
operationally  tested.  After  testing,  the  problem  is  either  corrected  or  not.  If  the  problem 
has  not  been  corrected,  the  contractor  re-attempts  repair  until  the  problem  is  resolved. 

D.  MODEL  INPUT 

The  following  section  defines  the  input  parameters  to  the  models.  Additionally, 
bounds  and  assumptions  of  the  model  are  disclosed. 

1,  Model  Setup 

As  illustrated  in  Figure  88,  Figure  90,  and  Figure  93,  the  system  fault  is  initialized 
by  an  “Initial  Problem”  block.  This  block  generates  a  system  problem  at  time  zero.  The 
problem  then  progresses  through  the  model.  When  the  issue  is  resolved,  the  age  of  the 
problem  is  calculated  and  recorded  in  a  database  at  line  one,  the  default  line  for  the 
simulation.  The  problem  is  then  delayed  by  a  probability  distribution  represented  by  the 
MTBM,  detailed  further  in  this  section,  and  exited  from  the  simulation  logic.  The  exit  of 
the  item  causes  the  exit  counter  to  increment  by  one.  The  counter  is  used  to  trigger  the 
next  problem  to  be  created  in  the  simulation.  Additionally,  the  counter  represents  the 
current  line  of  the  database  entry.  So,  one  is  added  to  the  counter  value  to  set  the  database 
line  location  for  entry  of  the  next  problem  resolution. 
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The  simulation  is  coufigiued  to  nm  to  represent  30  systems  operating  for  20  years 
each.  Simulations  are  nm  sequentially  for  ease  of  data  collection  but  represent  the  same 
outcome  as  if  they  were  nm  in  parallel.  The  simulation  is  set  to  nm  for  600  system-years 
which  equates  to  5,259,600  horns  shown  m  Table  12.  A  key  consideration  is  that 
sunulations  with  lower  times  to  repah  will  have  a  greater  number  of  faihnes  over  a  20- 
year  system  life,  as  the  system  spends  more  time  operational  and  subject  to  the  MTBM. 


Table  12.  Time  Bases  Model  Time  Parameter 


Hours/Y  ear 

Systems/Ship 

Ships 

Years 

Total 

HEL 

8766 

1 

30 

20 

5,259,600  HEL 
Systems  Homs 

2.  Data  Validation  and  Parameter  Restriction  Due  to  Classification 

The  USN  has  many  inconsistent  somces  of  reliability  data  that  is  reported 
aggregated  to  the  technical  conmiimity.  Detailed  probability  distribirtions  of  each  process, 
as  needed  for  the  model,  are  not  cimently  available.  System  performance  parameters  sitch 
as  MTBF/MTBM,  Ao,  and  mean  time  to  repair  (MTTR)  are  designated  for  official  use 
only  (FOUO)  and  above.  For  this  reason,  the  models  were  built  irsing  aggregate 
knowledge  and  estimations  across  mirltiple  established  systems.  The  airthors  of  this  effort 
are  self-somces  for  releasable  estimates  of  distance  support  tunes  arrd  probability 
distribirtions  for  relevant  USN  weapon  systems,  hr  this  way,  no  FOUO  or  above 
performance  information  is  needed  fiom  any  fielded  systems.  By  drawing  parallels  across 
models,  the  differences  can  be  studied  without  the  need  for  im-releasable  data.  It  is 
suggested  as  a  follow-on  effort  to  review  and  update  USN  reliability  reporting  to  include 
detailed  probability  distributions  for  all  sub-categorized  resolution  activities  to  assist  hr 
validating  this  and  firtme  DS  models. 

3.  Model  Parameters  and  Assumptions 

Parameters  of  the  models  are  detailed  in  the  followmg  sections:  time  scale, 

general  assumptions,  mean  time  between  maintenance,  mean  time  between  faihue,  and 

statirs  quo  distance  support  values,  integrated  distance  sirpport  values,  no  distance  support 
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values,  integrated  distance  support  evolution  from  status  quo  distance  support,  and  no 
distance  support  evolution  from  status  quo  distance  support. 

a.  Time  Scale 

All  time  parameters  are  in  hours.  Because  operations  of  a  ship  are  day  and  night 
and  not  subject  to  office  working  hours,  support  and  repair  are  to  be  measured  the  same. 
Hours  in  the  model  are  assumed  to  be  true  day  hours,  twenty-four  in  a  day. 

b.  General  Assumptions 

Values  entered  into  this  model  are  publically  releasable.  No  value  is 
representative  of  any  single  fielded  system.  These  are  an  aggregate  of  multiple  system 
broad  estimates  in  order  to  avoid  classification  restrictions.  When  appropriate,  values  and 
distributions  are  the  same  across  all  three  models  in  order  to  minimize  unintended 
variation. 

The  models  depict  the  vast  majority  of  repair  attempts  made  to  fielded  systems 
and  to  theoretical  systems.  However,  it  does  not  cover  all  cases.  It  is  believed  that  a  large 
enough  portion  of  all  cases  follow  the  models’  paths  to  deliver  useful  results.  A 
suggestion  for  future  work  is  to  expand  the  model  to  include  obscure  case  paths. 

c.  Mean  Time  between  Maintenance 

In  the  model,  MTBF  is  substituted  for  MTBM  and  the  terms  are  used 
interchangeably.  The  assumption  is  made  that  no  preventative  maintenance  will  be 
performed  unless  all  supplies  and  tools  are  available  to  perform  the  prescribed 
maintenance.  Also,  it  is  assumed  that  all  preventative  maintenance  shall  take  no  more 
than  two  hours.  Given  the  duration  necessary  to  perform  preventative  maintenance  is  so 
small,  a  separate  parameter  was  not  created  and  the  two  hour  duration  lumped  in  with  the 
total  MTBM  parameter.  For  clarity,  the  more  common  term  of  MTBF  is  used  through  the 
model. 
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d.  Mean  Time  between  Failure 

MTBF  is  assumed  to  be  500  Homs.  It  is  also  assumed  that  the  tuue  betweeu 
failures  follows  a  iionnal  distribiitiou.  Tliis  is  the  same  for  all  three  models. 


e.  Status  Quo  Distance  Support  Values 


Table  13.  Model  Parauieters — Status  Quo  Distauce  Support  Vahres 


Parameter 

Line 

Block 

Distribution 

Mean 

(Hours) 

SD 

(Hours) 

% 

Yes 

MTBF 

♦ 

268 

Nomial 

500 

100 

Sailor  Diagnose 

I 

2 

Normal 

24 

12 

Sailor  Attempt  Repah? 

3 

Percentage 

80 

Sailor  Need  Part? 

4 

Percentage 

80 

Part  Onboard? 

5 

Percentage 

20 

Sailor  Order  Part 

6 

Lognormal 

24 

12 

Sailor  Receive  Part 

7 

Lognormal 

72 

24 

Sailor  Optest 

8 

Normal 

12 

6 

Sailor  Fixed? 

9 

Percentage 

70 

Sailor  Re-Attempt  Repair? 

37 

Percentage 

10 

RMC  Diagnose 

2 

48 

Nomial 

48 

24 

RMC  Attempt  Repair  ? 

49 

Percentage 

80 

RMC  Need  Part? 

50 

Percentage 

90 

Part  Onboard? 

51 

Percentage 

20 

RMC  Order  Part 

52 

Lognormal 

24 

12 

RMC  Receive  Part 

53 

Lognormal 

72 

24 

RMC  Optest 

54 

Normal 

12 

6 

RMC  Fixed? 

55 

Percentage 

80 

RMC  Re-Attempt  Repair  ? 

83 

Percentage 

10 

ISEA  Diagnose 

3 

104 

Normal 

48 

24 

ISEA  Attempt  Repair  ? 

105 

Percentage 

95 

ISEA  Need  Part? 

106 

Percentage 

90 

Part  Onboard? 

107 

Percentage 

20 

ISEA  Order  or  Scavenge 

108 

Lognormal 

12 

6 

ISEA  Receive  Part 

109 

Lognormal 

24 

6 

ISEA  Optest 

110 

Normal 

12 

6 

ISEA  Fixed? 

111 

Percentage 

90 

ISEA  Re-Atternpt  Repair? 

139 

Percentage 

80 

Flyaway 

4 

187 

Normal 

48 

24 

Flyaway  Diagnose 

156 

Normal 

24 

12 

Flyaway  Need  Part? 

158 

Percentage 

90 

Part  Onboard? 

159 

Percentage 

20 

ISEA  Order  or  Scavenge 

160 

Lognormal 

12 

6 
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Parameter 

Line 

Block 

Distribution 

Mean 

(Hours) 

SD 

(Hours) 

% 

Yes 

Flyaway  Receiye  part 

161 

Loaiormal 

24 

6 

Flyaway  Optest 

162 

Nonnal 

6 

3 

Flyaway  Fixed? 

201 

Percentage 

95 

f.  Integrated  Distance  Support  Values 


Table  14.  Model  Parameters — Integrated  Distance  Support  Values 


Parameter 

Line 

Block 

Distribution 

Mean 

(Hours) 

SD 

(Hours) 

% 

Yes 

MTBF 

* 

63 

Normal 

500 

100 

DS  Diagnose 

2 

Normal 

24 

12 

DS  Need  Part? 

4 

Percentage 

80 

Part  Onboard? 

5 

Percentage 

20 

ISEA  Order  or  Scayenge 

1 

6 

Lognormal 

12 

6 

Sailor  Receive  Part 

7 

Lognormal 

48 

12 

DS  Optest 

8 

Normal 

12 

6 

DS  Fixed? 

9 

Percentage 

90 

DS  Re- Attempt  Repair? 

37 

Percentage 

90 

Flyaway 

187 

Normal 

48 

24 

Flyaway  Diagnose 

156 

Normal 

24 

12 

Flyaway  Need  Part? 

158 

Percentage 

90 

Part  Onboard? 

2 

159 

Percentage 

20 

ISEA  Order  or  Scavenge 

160 

Lognormal 

12 

6 

Flyaway  Receive  Part 

161 

Lognormal 

24 

6 

Flyaway  Optest 

162 

Normal 

6 

3 

Flyaway  Fixed? 

201 

Percentage 

95 
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No  Distance  Support  Values 


g- 


Table  15.  Model  Parameters — ^No  Distance  Support  Values 


Parameter 

Line 

Block 

Distribution 

Mean 

(Hours) 

SD 

(Hours) 

% 

Yes 

MTBF 

* 

268 

Noimal 

500 

100 

Sailor  Diagnose 

1 

2 

Nomial 

24 

12 

Sailor  Attempt  Repair? 

3 

Percentage 

80 

Sailor  Need  Part? 

4 

Percentage 

80 

Part  Onboard? 

5 

Percentage 

5 

Sailor  Order  Part 

6 

Lognoimal 

24 

12 

Sailor  Receive  Part 

7 

Lognoimal 

168 

48 

Sailor  Optest 

8 

Nomial 

12 

6 

Sailor  Fixed? 

9 

Percentage 

20 

Sailor  Re- Attempt 

37 

Percentage 

50 

Port  Call 

2 

78 

Lognoimal 

720 

120 

Contractor  Diagnose 

48 

Noimal 

24 

12 

Contractor  Need  Part? 

50 

Percentage 

90 

Part  Present? 

51 

Percentage 

20 

Order  or  Scavenge  Part 

52 

Lognoimal 

24 

12 

Contractor  Receive  part 

53 

Lognoimal 

96 

48 

Contractor  Optest 

54 

Noimal 

12 

6 

h.  Integrated  Distance  Support  Evolution  from  Status  Quo  Distance 
Support 

Table  16  depicts  the  differences  between  the  Status  Quo  Distance  Support  Model 
and  the  Integiated  Distance  Support  Model  as  well  as  explanations  for  the  value 
differences.  Positive  impacts  on  repan  time  are  denoted  in  green  and  negative  impacts  are 
denoted  in  red. 
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Table  16.  Integrated  Distanee  Support  Evolution  from  Status  Quo  Distance  Support 


Status  Quo 

Integrated  Support 

Justification 

Parameter 

Line 

Block 

Distribution 

Mean 

(Hours) 

SD 

(Hours) 

% 

Yes 

Parameter 

Line 

Block 

Distribution 

Mean 

(Hours) 

SD 

(Hours) 

% 

Yes 

MTBF 

* 

268 

Normal 

500 

100 

MTBF 

* 

63 

Nonnal 

500 

100 

Sailor  Diagnose 

1 

2 

Normal 

24 

12 

DS  Diagnose 

1 

2 

Nonnal 

24 

12 

Constrained  by  Sailor  and  Ship  Operations  Schedule 

Sailor  Attempt  Repair? 

3 

Percentage 

80 

Sailor  Need  Part? 

4 

Percentage 

80 

DS  Need  Part? 

1 

4 

Percentage 

80 

Part  Onboard? 

5 

Percentage 

20 

Part  Onboard? 

5 

Percentage 

20 

Sailor  Order  Pait 

6 

Lognonnal 

24 

12 

ISEA  Order  or  Scavenge  Pait 

6 

Lognormal 

12 

6 

ISEA  has  pan  loaning  and  scavenging  available  at  its  discretion 

Sailor  Receive  Part 

7 

Lognormal 

72 

24 

Sailor  Receive  Part 

7 

Lognormal 

48 

12 

ISEA  has  overnight  shipping  available  for  scavenged  part 

Sailor  Optest 

8 

Normal 

12 

6 

DS  Optest 

8 

Normal 

12 

6 

Sailor  Fixed? 

9 

Percentage 

70 

DS  Fixed? 

9 

Percentage 

90 

ISEA  assistance  tlirough  DS  is  expected  to  significantly  improve  probability  of 
fault  resolution 

Sailor  Re -Attempt  Repair? 

37 

Percentage 

10 

DS  Re -Attempt  Repair? 

37 

Percentage 

90 

Status  Quo  culture  dictates  passing  up  to  the  next  level  of  repair  With  DS, 

ISEA  assistance  is  alreadv  retained  So,  re-attempt  bv  remote  is  hiehlv  likelv 

RMC  Diagnose 

2 

48 

Normal 

48 

24 

RMC  Attempt  Repair? 

49 

Percentage 

80 

RMC  Need  Part? 

50 

Percentage 

90 

Part  Onboard? 

51 

Percentage 

20 

RMC  Order  Part 

52 

Lognormal 

24 

12 

RMC  Receive  Part 

53 

Lognonnal 

72 

24 

RMC  Optest 

54 

Normal 

12 

6 

RMC  Fixed? 

55 

Percentage 

80 

RMC  Re-Attempt  Repair? 

83 

Percentage 

10 

ISEA  Diagnose 

3 

104 

Normal 

48 

24 

ISEA  Attempt  Repair? 

105 

Percentage 

95 

ISEA  Need  Part? 

106 

Percentage 

90 

Part  Onboard? 

107 

Percentage 

20 

ISEA  Order  or  Scavenge  Part 

108 

Lognormal 

12 

6 

ISEA  Receive  Part 

109 

Lognormal 

24 

6 

ISEA  Optest 

no 

Normal 

12 

6 

ISEA  Fixed? 

111 

Percentage 

90 

ISEA  Re- Attempt  Repair? 

139 

Percentage 

80 

Flyaway 

4 

187 

Normal 

48 

24 

Flyaway 

2 

187 

Normal 

48 

24 

Flyaway  Diagnose 

156 

Normal 

24 

12 

Flyaway  Diagnose 

156 

Normal 

24 

12 

Flyaway  Need  Part? 

158 

Percentage 

90 

Flyaway  Need  Part? 

158 

Percentage 

90 

Part  Onboard? 

159 

Percentage 

20 

Part  Onboard? 

159 

Percentage 

20 

ISEA  Order  or  Scavenge  Part 

160 

Lognormal 

12 

6 

ISEA  Order  or  Scavenge  Part 

160 

Lognoimal 

12 

6 

Flyaway  Receive  part 

161 

Lognormal 

24 

6 

Elyaway  Receive  part 

161 

Lognormal 

24 

6 

Flyaway  Optest 

162 

Normal 

6 

3 

Flyaway  Optest 

162 

Normal 

6 

3 

Flyaway  Fixed? 

201 

Percentage 

95 

Flyaway  Fixed? 

201 

Percentage 

95 

199 


Table  17.  No  Distance  Support  Evolution  from  Status  Quo  Distance  Support 


MTBF 
Sailor  Diagnose 


Sailor  Need  Part? 
Part  Onboard? 


RMC  Diagnose 


RMC  Attempt  Repair? 


RMC  Need  Part? 
Part  Onboard? 


RMC  Order  Part 


RMC  Receive  Part 


RMC  Optest 


Status  Quo 


Sailor  Attempt  Repair? 


Sailor  Order  Part 


Sailor  Receive  Part 


Sailor  Optest 


Sailor  Fixed? 


Sailor  Re- Attempt  Repair? 


RMC  Fixed? 


RMC  Re- Attempt  Repair? 


ISEA  Diagnose 


ISEA  Attempt  Repair? 


ISEA  Need  Part? 


Part  Onboard? 


ISEA  Order  or  Scavenge  Part 


ISEA  Receive  Part 


ISEA  Optest 


ISEA  Fixed? 


ISEA  Re-Attempt  Repair? 


Flyaway 


Flyaway  Diagnose 


Flyaway  Need  Part? 


Part  Onboard? 


ISEA  Order  or  Scavenge  Part 
Flyaway  Receive  part 


Flyaway  Optest 


Flyaway  Fixed? 


Line 


Block 

268 


37 


49 


53 


Normal 


55 


83 


105 


107 


109 


111 


139 


187 


159 


160 

161 


201 


Distribution 
Normal 


Normal 


Percentage 


Percentage 

Percentage 


Lognormal 


Lognormal 


Normal 


Percentage 


Percentage 


Normal 


Percentage 


Percentage 

Percentage 


Lognormal 


Lognormal 


Percentage 


Percentage 


Normal 


Percentage 


Percentage 


Percentage 


Lognormal 


Lognormal 


Normal 


Percentage 


Percentage 


Normal 


Normal 


Percentage 


Percentage 


Lognormal 

Lognormal 


Normal 


Percentage 


Mean 

(Hours) 

500 


72 


72 


24 


SD 

(Hours) 

100 


24 


24 


JustiHcation 


90 


20 


95 


[Minimal  to  no  spares  onboard 


Lack  of  a  robust  supply  system  support,  dependence  on  contractor 


[Lack  of  training  due  to  dependence  on  contractor  support 


|No  help  is  available  until  port  re-attempt  is  significantly  more  likely 


Contractor  Diagnose 


Contractor  Need  Part? 


Part  Present? 


Order  or  Scavenge  Part 
Contractor  Receive  part 


Contractor  Optest 


Contractor  Fixed? 


48 

Nonnal 

50 

Percentage 

51 

Percentage 

52 

Lognonnal 

53 

Lognormal 

54 

Nonnal 

201 

Percentage 

[No  support  method  is  based  on  leaving  systems  broken  until  the  ship 

It  is  assumed  that  the  contractor  will  be  remotely  notified  and  flyout  to 
meet  the  ship 


20 


90 


Less  spares  available  than  a  robust  ISEA  and  supply  system _ 

Parts  maybe  located  out  of  country  or  endure  contractual  issues  for 
Ship's  attention  is  divided  in  port 
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7.  No  Distance  Support  Evolution  from  Status  Quo  Distance  Support 

Table  17  depicts  the  differences  between  the  Status  Quo  Distance  Support  Model 
and  the  No  Distance  Support  Model  as  well  as  explanations  for  the  value  differences. 
Positive  impacts  on  repah  time  are  denoted  in  green  and  negative  impacts  are  denoted  in 
red. 

E.  SUMMARY 

The  following  sections  summarize  the  results  of  the  M&S  Effort.  Details  of  the 
Frequency  and  Time  Models  are  presented  below. 

1.  Frequency  Models 

The  results  of  the  Frequency  Models  below  provide  a  high-level  analysis  on  MDT 
and  Ao  as  single  values.  Tlie  hitegrated  Distance  Suppoil  Model  shows  significant 
improvement  over  the  Status  Quo  Distance  Support  Model,  increasmg  Ao  from  77.6%  to 
85.6%  without  modifying  the  system  to  improve  MTBM. 

The  No  Distance  Suppoit  Model  shows  significant  diminishmeut  with  respect  to 
the  Status  Quo  Distance  Support  Model,  decreasing  Ao  from  77.6%  to  61.6%  without 
modifying  the  system  to  affect  MTBM.  Key  results  are  denoted  in  bold  in  Table  18. 


Table  18.  Frequency  Models 


Parameter 

Status  Quo 

DS 

Integrated 

Distance 

Support 

No  Distance 
Support 

Units 

Mean  Time  Between 

Maintenance  (MTBM) 

500 

500 

500 

Hours 

Mean  Down  Time  (MDT) 

=  Mbar  +  MLDT  +  MAdmDT 

144 

84 

312 

Hours 

Mean  Active  Maintenance  Time 
(Mbar) 

48 

24 

96 

Hours 

Mean  Logistics  Delay  Time 
(MLDT) 

48 

36 

168 

Hours 

201 


Parameter 

Status  Quo 
DS 

Integrated 

Distance 

Support 

No  Distance 
Support 

Units 

Mean  Admirustrative  Delay 

Time 

48 

24 

48 

Horns 

Operational  Availability  (Ao) 

=  MTBM/(MDT  +  Mbar) 

0.776 

0.856 

0.616 

2.  Time  Models 

The  results  of  the  Time  Models  below  provide  a  detailed  analysis  on  MDT  and  Ao 
as  probability  distributions. 

a.  Time  Model — Status  Quo  Distance  Support  Results 

As  illustrated  in  Figme  94,  the  Status  Quo  Distance  Support  Model  results  show 
two  distmct  areas  of  repah  times.  The  shorter  time  window  is  believed  to  be  a  distorted 
normal  distribution  representing  system  problems  fixed  in  one  attempt,  withorrt  orrtside 
assistance.  The  second  window  of  repah  times  is  believed  to  be  a  distorted  Normal 
distribrrtion  representing  mrrltiple  repah  attempts  and  rmrltiple  repah  entities 
participating.  Remaining  vahtes,  hi  excess  of  200  horns  are  believed  to  be  associated  with 
required  flyaway  support  and  multiple  rormds  of  re-attempted  repah  of  the  system  by  the 
same  repah  entity. 

Tire  MDT  for  the  Stahrs  Quo  Distance  Srrpport  Model  is  149.0  Horns  with  a 
standard  deviation  of  91.5  Horns.  The  coiiesponding  Ao  is  0.770.  These  results  are 
believed  to  be  consistent  with  an  aggregation  of  considered  fielded  systems.  Results  are 
summarized  in  Table  19. 
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DSHEL  -  Status  Quo  Distance  Support 
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Figure  94.  Status  Quo  Distance  Support — Down  Time 


b.  Time  Model — Integrated  Distance  Support  Results 

As  illustrated  in  Figure  95,  the  Integrated  Distance  Support  Model  results  show 
two  distinct  areas  of  repair  times.  The  shorter  time  window  is  believed  to  be  a  distorted 
Normal  distribution  representing  system  problems  fixed  in  one  attempt.  The  second 
window  of  repair  times  is  believed  to  be  a  distorted  normal  distribution  representing 
multiple  repair  attempts.  Remaining  values,  in  excess  of  140  hours  are  believed  to  be 
associated  with  required  flyaway  support  and  multiple  rounds  of  re-attempted  repair  of 
the  system. 

The  MDT  for  the  Status  Distance  Support  Model  is  83.8  Hours  with  a  standard 
deviation  of  44.9  Hours.  The  corresponding  Ao  is  0.856.  These  results  are  derived  from 
status  quo  values,  only  modified  for  differences  in  the  support  methodologies,  and 
accepted  as  reasonable.  Results  are  summarized  in  Table  19. 
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DSHEL  -  Integrated  Distance  Support 
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Figure  95.  Integrated  Distanee  Support — Down  Time 
c.  Time  Model — No  Distance  Support  Results 

As  illustrated  in  Figure  96,  the  No  Distance  Support  Model  results  show  two 
distinct  areas  of  repair  times.  The  shorter  time  window  is  believed  to  be  an  approximate 
Normal  distribution  representing  system  problems  fixed  by  the  sailor,  onboard,  without 
assistance.  The  second  window  of  repair  times  represents  multiple  repair  attempts  by  the 
sailor  or  waiting  for  contractor  support  when  the  ship  returns  to  port. 

The  MDT  for  the  No  Distance  Support  Model  is  335.1  Hours  with  a  standard 
deviation  of  210.5  Hours.  The  corresponding  Ao  is  0.559.  These  results  are  derived  from 
status  quo  values,  only  modified  for  differences  in  the  support  methodologies,  and 
accepted  as  reasonable.  Results  are  summarized  in  Table  19. 
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DSHEL  -  No  Distance  Support 


Down  Time  (Hours) 


Figuie  96.  No  Distance  Support — ^Down  Time 

d.  Time  Model — Summary  Distance  Support  Results 

Table  19  is  a  summaiy  of  all  thiee  Time  Model  Results.  The  results  below  are 
denoted  best  to  worst  by  green,  yellow,  and  red,  respectively.  All  model  files  are 
available  upon  request  fi'om  Tire  SE  Department  of  NFS. 


Table  19.  Time  Models  Summary  Results 


Parameter 

Status  Quo 
Distance 
Support 

Integrated 

Distance 

Support 

No  Distance 
Support 

Units 

Mean  Down  Time 
(MDT) 

148.97 

83.79 

335.05 

Homs 

Down  Time  (SD) 

91.45 

44.86 

210.50 

Homs 

Operational  Availability 

(Ao) 

0.770 
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VI.  COST  AND  RISK  ANALYSIS 


This  chapter  explores,  estimates,  and  provides  in-depth  analysis  regarding  the 
various  costs  and  risks  associated  with  the  realization  of  DSHEL.  Recommendations  for 
the  best  path  forward  are  summarized  in  each  of  the  analysis  results. 

A.  COST  ANALYSIS  APPROACH 

The  following  seetion  addresses  the  various  SE  methodologies  and  estimation 
techniques  for  analyzing  the  cost  impact  of  DSHEE. 

1.  Systems  Engineering 

The  initial  SE  efforts  during  the  aequisition  phase  of  development  eontribute  to  a 
considerable  amount  of  effort  in  terms  of  labor.  This  ranges  from  the  aequisition,  supply, 
technical  management,  system  design,  produet  realization,  to  the  test  and  evaluation  type 
activities  which  span  from  concept  realization  to  operational  transition.  The  aeeepted 
approaeh  for  estimating  the  eost  of  these  SE  aetivities  is  the  Constructive  Systems 
Engineering  Model  (COSYSMO)  as  leveraged  in  this  chapter.  The  assumptions  driving 
the  COSYSMO  input  variables  of  the  eost  estimation  model  were  leveraged  from 
material  already  covered  in  this  report,  e.g.,  number  of  requirements,  interfaces,  and 
diversity  of  installation  platforms.  Onee  obtained,  these  values  were  used  as  the  system 
size  and  system  cost  driver  attributes  in  the  NPS  COSYSMO  Systems  Engineering  Cost 
Model  Advisor  software  tool  to  compute  an  estimate  of  SE  cost  (Madachy,  COCOMO 
Suite  of  Construetive  Cost  Models  2014). 

2,  Software  Engineering 

The  Constructive  Cost  Model  II  (COCOMO  II)  is  widely  used,  thoroughly 
doeumented,  and  calibrated  software  cost  model.  COCOMO  II  provides  a  methodology 
similar  to  COSYSMO  where  the  model  offers  insight  into  the  root  eause  of  cost 
variations.  The  overall  effort  is  provided  in  person-months  to  help  the  project  lead  create 
an  accurate  schedule.  One  of  the  key  inputs  of  this  tool  is  the  logieal  Source  Eines  of 
Code  (SEOC).  To  obtain  this,  research  was  performed  weighing  the  needs  of  DSHEE’s 

207 


functional  requirements  against  available  software  applieations.  Onee  an  applieation  was 
seleeted  as  a  eandidate  for  estimation,  a  fimotional  SLOC  eount  was  performed.  To 
perform  this  SLOC  eount,  a  tool  was  leveraged  from  the  University  of  Southern 
California  (USC)  Center  for  Systems  and  Software  Engineering  (CSSE),  known  as  the 
Unified  Code  Count  (UCC)  (University  of  Southern  California  2014).  CSSE  provides  the 
raw  open  souree  eode  of  UCC.  This  source  eode  was  eompiled  by  the  team  using  the 
GNU  Compiler  Colleetion  G++  applieation  under  the  Eedora  Operating  System.  This  tool 
was  used  to  analyze  the  applieation  eandidate  souree  eode  to  produee  SEOC  metries  as  a 
COCOMO  II  input  parameter.  Eollowing  this,  the  eonstruetive  analysis  of  software  input 
parameters  based  on  earlier  researeh  in  this  report,  alongside  given  assumptions,  were 
used  to  produee  an  overall  estimate  of  the  software  engineering  aetivities  during  the 
aequisition  phase  of  DSHEE. 

3.  Hardware  Engineering 

Hardware  eost  estimates  for  a  subsystem  are  unique  when  it  comes  to  seleeting  a 
methodology.  Traditionally,  the  Advanced  Mission  Cost  Model  (AMCM)  is  used  for  SE 
projeet  estimations.  However,  that  particular  model  is  slated  for  large  seale  projeets  sueh 
as  ships,  tanks,  and  eomplete  weapon  systems.  In  the  ease  of  DSHEE  being  a  small 
eomponent,  it  was  the  reeommendation  of  NFS  Professor  Raymond  Madaehy  to  eost  out 
and  eompute  direetly,  given  that  AMCM  does  not  seale  down  for  estimates  this  small  in 
projeet  size.  Therefore,  the  proposed  methodology  was  to  perform  market  researeh  of 
eommon  naval  eomputing  equipment  already  used  in  the  shipboard  enterprise,  seleet  and 
eompile  the  eosts,  and  then  multiply  by  the  estimated  number  of  shipboard  installations 
of  HEE  to  determine  the  material  eost  of  the  proposed  DSHEE  subsystem. 

4.  Sustainment  Engineering 

Sustainment  engineering  refers  to  the  eosts  ineurred  by  the  program  neeessary  for 
the  ISEA  eommunity  to  sustain  DSHEE  onee  it  is  operational.  This  involves  a  variety  of 
faetors,  however,  the  basie  methodology  tailored  for  DSHEE  will  inelude  the  hardware, 
software,  and  logistieal  support.  Eor  hardware,  an  assumption  has  been  made  regarding 
the  neeessary  obsolescenee  management  for  the  two  major  DSHEE  eomponents. 
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diminishing  manufacturing  sources  and  material  shortages  (DMSMS)  processes  manage 
the  obsolescence  of  the  hardware.  The  hardware  will  therefore  follow  the  standard  five 
year  teehnical  refresh  model  as  dietated  by  USN  ISEAs.  The  initial  sparing  cost  will  also 
be  included.  Software  sustainment  costs  follow  a  similar  methodology,  however, 
leveraging  the  extension  of  software  license  management.  The  software  process  is 
eomputed  by  the  annual  cost  of  licenses  multiplied  by  the  number  of  shipboard 
installations  of  HEL.  Both  endeavors  include  the  addition  of:  SE  efforts,  hardware 
engineering  efforts,  regression  testing,  and  logistical  efforts  for  engineering  ehange 
proposal  review  and  configuration  management. 

5,  Life-Cycle  Cost  Benefit  Analysis 

To  perform  the  eost  benefit  analysis,  the  entire  life-cycle  eost  of  DS  must  be  taken 
into  account.  This  includes  the  cost  of  acquisition  systems,  software,  hardware,  and 
sustainment  engineering  in  addition  to  the  eost  per  teehnieal  assistance  in  supporting  the 
Eleet.  The  methodology  for  estimating  this  eost  is  ealeulated  by  taking  the  summation  of 
all  aequisition  and  sustainment  costs  and  dividing  by  the  expected  serviee  life.  This 
results  in  the  annual  cost  for  DS.  By  taking  known  costs  of  technical  assistance  to  the 
Eleet  with  and  without  DS,  the  annual  cost  of  DSHEE  can  be  added  to  the  effort  per  eaeh 
teeh  assist  and  plotted  against  the  cost  of  no  DS.  In  turn,  the  point  at  whieh  the  lines 
interseet  is  the  breakeven  point.  This  is  where  DSHEE  begins  to  “pay  for  itself’  and 
reduces  life-cycle  eost  to  the  HEE  program. 

B,  COST  ANALYSIS  AND  RESULTS 

The  following  section  shall  present  the  application  results  from  the 
aforementioned  SE  methodologies  and  estimation  teehniques  used  in  analyzing  the  eost 
impaet  of  DSHEE. 

1,  Systems  Engineering 

The  system  size  and  system  eost  driver  attributes  of  the  COSYSMO  estimation 
methodology  required  numerous  variables  be  explored  and  defined.  This  seetion 
iteratively  explored  each  such  variable,  its  relation  to  DSHEE  based  on  the  research 
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provided  thus  far  in  this  report,  and  a  rationale  as  to  the  seleetion  for  its  attribute  ranking 
based  on  aeeepted  disposition  definitions  from  the  SE  Cost  Estimation  Workbook 
(Madaehy,  Systems  Engineering  Cost  Estimation  Workbook  2014). 

The  number  of  DSHEE  speeifie  “system  requirements”  was  based  on  the  quantity 
of  those  related  to  engineering  the  system  interfaees,  system  speeifie  algorithms,  and 
operational  seenarios.  While  these  may  be  grouped  as  funetional,  performanee,  or  serviee 
oriented,  they  are  counted  once  decomposed  to  the  lowest  work  breakdown  structure 
allocation  to  avoid  duplication  of  effort.  Based  on  the  results  of  the  Requirements 
Analysis  chapter,  DSHEE  had  a  total  of  19  high  level  requirements.  All  19  were 
determined  to  be  difficult,  given  they  were  complex  to  engineer  or  implement,  hard  to 
trace  to  the  source,  contained  a  high  degree  of  overlap,  and  required  further 
decomposition  from  the  USN  Distance  Support  Handbook. 

The  number  of  “system  interfaces”  was  based  on  the  quantity  of  internally  shared 
physical  and  logical  boundaries  between  DSHEE  components  and  functions,  as  well  as 
those  external  to  the  system.  Eormally,  these  can  be  defined  by  ISO/IEC  15288  defined 
system  elements.  Based  on  the  results  of  Chapter  IV,  DSHEE  has  a  total  of  32  interfaces. 
Of  those,  21  were  determined  to  be  easy  based  on  the  interface  providing  transport  of 
simple  uncoupled  messages,  being  well  behaved,  and  having  strong  consensus.  The  count 
of  21  resulted  from  the  three  interface  types  of  keyboard,  video,  and  mouse  interfacing 
across  seven  main  components  of  the  platform  of  interest.  Eleven  were  determined  to  be 
nominal  given  moderate  complexity  of  the  protocols,  being  loosely  coupled,  having 
moderate  consensus,  and  predictable  behavior.  Among  the  sensor  suite,  beam  former, 
optical  bench,  storage,  power,  and  DSHEE  server,  none  were  determined  to  be  difficult, 
composed  of  highly  coupled  or  complex  protocols. 

The  number  of  “System  Algorithms”  was  based  on  newly  defined  or  altered  reuse 

functions,  which  require  mathematical  functions  to  be  created  in  order  to  meet  system 

performance  requirements.  Given  the  focus  of  DSHEE  in  this  report  is  scoped  to  the 

initial  four  pillars  of  DS,  the  number  of  algorithms  are  minimal  given  that  the  final  two 

pillars  of  ePrognostics  and  Self  Repair  were  slated  for  future  work.  Remote  Monitoring 

involves  an  algebraic  filter,  which  would  send  the  appropriate  system  status  results  of 
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health,  sensor,  and  BIT  passively  to  the  shore.  Alongside  these  are  also  the  network 
infrastrueture  status  between  the  DSHEL  system  and  the  ship’s  router,  an  external  health 
status  message  to  the  system  necessary  for  having  situational  awareness  of  the 
environment  while  troubleshooting.  Given  this  is  straightforward,  algebraic,  and  a  simple 
data  type,  the  number  of  easy  algorithms  was  determined  to  be  four;  whereas  the  number 
of  nominal  and  difficult  algorithms  was  determined  to  be  zero. 

The  number  of  “operational  scenarios”  was  based  on  the  normal  stimulus- 
response  based  operations  alongside  the  malfunctioning  scenarios  in  which  DSHEL 
cannot  operate  properly  (e.g.,  unavailable  external  systems,  network  connections  or  other 
interfaces,  and  invalid  data).  Given  the  focus  of  DSHEL  in  this  report  is  scoped  to  the 
initial  four  pillars  of  DS;  the  normal  operation  count  was  determined  to  be  four  nominal 
scenarios.  Given  the  areas  where  exception  handling  of  HEL  to  DSHEL  communication, 
bad  data,  infrastructure  downtime,  and  satellite  link  malfunctions  being  non-normal 
operating  conditions,  the  scenarios  were  determined  to  be  two  difficult  and  two  nominal. 
The  aggregate  inputs  for  operational  scenarios  were  then  determined  to  be  zero  easy,  six 
nominal,  and  two  difficult. 

“Requirements  understanding”  encompasses  the  overall  comprehension  of  system 
requirements  by  all  stakeholders.  While  this  report  presents  the  DSHEL  requirements  and 
decomposes  to  a  reasonable  level,  some  areas  were  already  determined  to  require  further 
analysis  given  the  HEL  systems  currently  in  the  EISN  are  in  test  bed  status  and  not  fully 
realized  as  a  program  of  record  (PoR).  Elntil  a  final  system  architecture  and  design  has 
been  selected  by  ONR  as  a  formal  PoR,  the  Requirements  Elnderstanding  of  DSHEL  shall 
remain  nominal,  translating  to  being  reasonably  understood  with  some  undefined  areas. 

“Architecture  Understanding”  relates  to  the  difficulty  in  determining  and 
managing  the  system  architecture  in  terms  of  the  platform,  components,  standards,  and 
infrastructure.  Similar  to  Requirements  Understanding,  this  report  presents  the  DSHEL 
architecture  and  decomposes  to  a  reasonable  level.  The  various  shipboard  platforms  were 
addressed  as  various  candidates,  given  their  unique  infrastructures  alongside  the  standard 
design  framework  of  a  SSL.  While  the  test  bed  has  not  been  fully  realized  as  a  PoR,  there 
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is  still  a  strong  understanding  of  the  various  arehiteetures,  GOTS  systems,  and  few 
unfamiliar  areas.  The  architeeture  understanding  was  determined  to  be  high. 

“Level  of  Service”  requirements  defines  the  criticality  and  difficulty  of  satisfying 
KPPs,  security,  response  time,  safety,  and  other  type  “-ility”  characteristics  of  the  system. 
Given  the  performance  and  suitability  requirements  for  DSHEL  alongside  the  recent 
DOD  memorandum  of  procedures  for  operational  test  and  evaluation  (OT&E)  of 
Cybersecurity  in  Acquisition  programs,  core  defense  performance  metrics  in  support  of 
cyber  reciprocity  for  HEE  (via  DSHEE)  drive  the  Eevel  of  Service  to  be  high  given  how 
coupled  these  parameters  are  and  the  impact  of  not  meeting  minimum  threshold. 

“Migration  Complexity”  refers  to  the  difficulty  and  extent  which  legacy  systems 
can  be  reused,  e.g.,  components,  databases,  workflows.  While  the  DSHEE  concept 
focuses  on  commercial  and  other  “bolt  on”  distance  support  technologies,  there  exists 
limited  to  no  legacy  DS  systems  for  reuse  alongside  the  HEE.  Merely  business  processes, 
lessons  learned,  studies,  and  the  research  from  this  capstone  report  serves  as  the  basis  for 
migration  of  DS  into  integration,  development,  architecture  and  design.  Therefore,  the 
migration  complexity  was  determined  to  be  very  high. 

The  overall  “Technology  Risk”  of  the  system  refers  to  the  maturity,  readiness,  and 
obsolescence  of  the  technology  being  implemented.  In  terms  of  DOD  systems,  there  is  a 
direct  correlation  to  the  Technology  Readiness  Eevel  (TRL)  which  is  used  to  assess 
maturity  of  evolving  technologies  during  their  development  and  early  operations. 
Providing  a  few  comparisons,  a  TRL  of  7  describes  readiness  of  a  prototype  where  there 
exists  a  demonstration  of  the  system  in  an  operational  environment.  A  TRL  of  8  would 
describe  readiness  where  an  actual  system  has  been  completed  and  qualified  through 
T&E  and  is  ready  for  widespread  adoption,  and  a  TRL  of  9  would  describe  readiness 
where  the  system  has  been  proven  through  many  operational  missions.  Using  the 
aforementioned  descriptions,  DSHEL  would  have  between  a  TRL  of  8  and  9.  Since  it 
does  not  fully  meet  the  readiness  of  TRL  9,  the  resulting  assessment  is  that  of  TRL  8. 
This  is  due  to  the  fact  that  distance  support  in  the  USN  has  already  been  proven  through 
T&E  and  limited  use  in  existing  tactical  systems.  While  not  the  standard  in  weapon  or 
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combat  systems,  it  is  qualified  and  ready  for  widespread  use.  Therefore,  the  teehnology 
risk  was  determined  to  be  low. 

Logistics  artifacts  such  as  documentation,  formality,  and  neeessary  detail  required 
for  delivery  of  the  DHSEL  component,  must  be  considered  when  taking  the  life-cycle 
support  into  account.  While  standard  NAVSEA  Eogistics  Center  requirements  mandate 
rigorous,  striet  standards  and  requirements,  the  detail  neeessary  to  guide  the  users  through 
DS  processes,  must  also  leverage  large  amounts  of  documentation  whieh  are  more 
rigorous  relative  to  the  life-cyele  needs.  This  is  due  to  the  cybersecurity  concerns  and 
adherence  to  process  complianee  for  neeessary  man-in-the-loop  operations  of  DS.  In  turn, 
this  leads  the  doeumentation  assessment  to  be  very  high. 

As  a  subsystem  eomponent  of  HEE,  DSHEE  would  then  be  installed  upon  the 
various  afloat  platforms  targeted  for  directed  energy  mission  employment.  Per  the  focus 
of  this  capstone  report  and  other  studies  performed  by  the  ONR,  this  is  to  foeus  on 
destroyers  and  eruisers  with  an  ISNS  eonfiguration  and  Eittoral  Combat  Ships  with  a 
Total  Ship  Computing  Environment.  The  number  of  install  configurations  is  estimated  to 
be  at  least  three.  However,  all  would  be  using  industry  standard  protocol  on  a  shipboard 
network.  The  operating  environment  would  also  meet  all  known  operational  requirements 
as  shipboard  data  rooms  are  environmentally  controlled  for  information  systems.  The 
diversity  of  “Installation  Platforms  was  therefore  determined  to  be  high. 

The  DSHEE  “Recursive  Eevels  of  Design”  span  not  only  vertical  and  horizontal 
coordination  between  subsystem  components,  but  also  relate  more  complex 
interdependencies  to  eoordinate  the  tradeoff  analysis  when  determining  whieh  HEE 
components  to  monitor.  Based  on  the  arehitecture  views  previously  created  alongside  the 
DS  framework  methodology,  the  reeursive  levels  point  to  a  nominal  assessment. 

“Stakeholder  Team  Cohesion”  defines  how  well  a  team  collaborates.  Euture 
inputs  to  stakeholder  team  cohesion  will  most  likely  eonsist  of  NAVSEA,  SPAWAR, 
ONR,  and  industry  partners.  The  team  is  eomposed  of  personnel  from  similar 
organizations,  share  projeet  culture,  compatible  organizational  objeetives,  and  clear  roles 
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and  responsibilities  as  defined  by  the  warfare  eenter  teehnieal  eapabilities.  Therefore, 
eohesion  was  determined  to  be  nominal. 

The  “Team  Capability”  best  deseribes  the  intelleetual  eapaeity  and  execution 
ability  to  analyze  complex  problems  and  manifest  solutions,  compared  to  the  national 
pool  of  SB’s.  Given  that  the  field  of  DS,  infrastructure,  and  naval  engineering  is 
proficient  with  SB,  this  was  determined  to  be  at  least  in  the  75th  percentile,  leading  to  an 
assessment  of  high. 

“Personnel  Bxperience  and  Continuity”  relate  to  the  applicability  and  consistency 
of  the  staff  at  the  initial  stage  of  the  project,  with  respect  to  the  system  domain,  customer, 
user,  and  technology.  Given  the  pool  of  naval  IT,  infrastructure,  and  systems  engineers 
who  have  already  been  in  the  test  bed  development  stage  of  HBB,  alongside  the  existence 
functional  resources  within  the  warfare  centers,  it  is  assumed  there  would  at  least  be  three 
years  continuous  experience  available  on  average,  and  a  turnover  of  less  than  12%.  The 
continuity  was  therefore  determined  to  be  nominal. 

The  “Process  Capability”  describes  the  consistency  and  effectiveness  of  the 
project  team  performing  the  SB  processes.  Given  the  current  industry  and  government 
HBB  teams  have  defined  SB  processes,  activities  driven  by  benefit  to  the  project,  a 
process  approach  driven  by  the  organizations  involved,  as  well  as  a  Capability  Maturity 
Model  Index  (CMMI)  assessment  level  of  3,  this  is  synonymous  with  a  high  process 
capability  per  the  Cost  Bstimation  Workbook. 

“Multisite  Coordination”  on  a  USN  project  is  an  area  that  covers  the  location  of 
stakeholders,  team  members,  resources,  and  corporate  collaboration  barriers.  Given  the 
naval  warfare  centers,  research  labs,  program  offices,  and  test  sites  span  the  reaches  of 
the  country  this  leads  to  a  team  which  is  remotely  collaborating  at  times.  However,  given 
criteria  defined  by  the  Cost  Bstimation  Workbook  as  usage  of  wideband  electronic 
communication,  Internet  based  teleconference,  and  interactive  development  environments 
which  employ  collaborative  tools  and  processes  in  place  to  mitigate  these  barriers;  the 
coordination  effort  averages  out  to  an  assessment  of  high. 
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Considering  the  “Tool  Support”  coverage,  integration,  and  matiuity  of  toolsets  in 
the  naval  SE  envuoument  is  readily  available,  uiatme,  and  integrated  with  other 
disciplines,  it  is  assirmed  these  same  resoiuces  will  also  be  available  to  the  DHSEL 
project  team.  The  tool  support  was  then  assessed  to  be  high. 

For  consistency  of  other  DS  cost  benefit  stirdies  performed,  the  labor  rate  was 
assumed  to  be  biudened  at  approximately  $10,000  per  person  month.  This  assumption 
was  made  for  the  reuse  of  Fleet  technical  assistance  data  and  describes  the  average  cost 
of  technical  assistance  with  and  without  distance  support  thereby  normalizing  the  person 
horns  used  between  the  DSHEL  estimates  and  existing  Fleet  data. 

Table  20  simimarizes  the  input  variables  determined  from  the  former  analysis  and 
was  used  as  mput  to  the  COSYSMO  tool,  as  well  as  the  resirlting  estimation  output  in 
Figme  97  and  Figirre  98. 


Table  20.  COSYSMO  Tool  hiput  Data 


Methodology  Variable 

Value 

System  Size  -  #  of  System  Requueuieuts  (Easy) 

0 

System  Size  -  #  of  System  Requuements  (Nominal) 

0 

System  Size  -  #  of  System  Reqiruemeuts  (Difficult) 

19 

System  Size  -  #  of  System  Interfaces  (Easy) 

21 

System  Size  -  #  of  System  Interfaces  (Nominal) 

11 

System  Size  -  #  of  System  Interfaces  (Difficult) 

0 

System  Size  -  #  of  Algor  ithms  (Easy) 

4 

System  Size  -  #  of  Algorithms  (Nomiual) 

0 

System  Size  -  #  of  Algoritlrms  (Difficult) 

0 

System  Size  -  #  of  Operational  Scenarios  (Easy) 

0 

System  Size  -  #  of  Operational  Scenarios  (Nominal) 

6 

System  Size  -  #  of  Operational  Scenarios  (Difficult) 

2 
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Methodology  Variable 

Value 

System  Cost  Drivers  -  Requirements  Understanding 

NOMINAL 

System  Cost  Drivers  -  Arcliitectme  Understanding 

HIGH 

System  Cost  Drivers  -  Level  of  Service  Requirements 

HIGH 

System  Cost  Drivers  -  Migration  Complexity 

VERY  HIGH 

System  Cost  Drivers  -  Technology  Risk 

LOW 

System  Cost  Drivers  -  Documentation 

VERY  HIGH 

System  Cost  Drivers  -  #  and  Diversity  of  Installations/Platfoims 

HIGH 

System  Cost  Drivers  -  #  of  Recursive  Levels  in  the  Design 

NOMINAL 

System  Cost  Drivers  -  Stakeholder  Team  Cohesion 

NOMINAL 

System  Cost  Drivers  -  Persormel/Team  Capability 

HIGH 

System  Cost  Drivers  -  Persoimel  Expeiience/Continuity 

NOMINAL 

System  Cost  Drivers  -  Process  Capability 

HIGH 

System  Cost  Drivers  -  Multisite  Coordination 

HIGH 

System  Cost  Drivers  -  Tool  Support 

HIGH 

Maintenance 

Off 

System  Labor  Rates 

$10000  /  Month 
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Expert  COSYSMO  -  Systems  Engineering  Cost  Model  Risk  Advisor 


Mcdel(s) 
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Figure  97.  COSYSMO  Data  Input 


Results 


Cost  and  Schedule 


Effort  =129  Person-months 
Schedule  =  7  Months 
Cost  =  $1290569 


Effort  Distribution  (Person-Months) 


Phase / 
Activity 

Conceptualize 

Develop 

Operational 
Test  and 
Evaluation 

Transition 

to 

Operation 

Acquisition 
and  Supply 

2.5 

4.6 

1.2 

0.7 

Technical 

Management 

4.8 

8.3 

5.5 

3.3 

System 

Design 

13.2 

15.5 

6.6 

3.5 

Product 

Realization 

2.5 

5.8 

6.2 

4.8 

Product 

Evaluation 

7.2 

10.8 

16.0 

6,0 

Figure  98.  COSYSMO  Analysis  Results 


Based  on  the  resulting  analysis,  it  can  be  estimated  the  total  SE  effort  during 
acquisition  would  be  129  person  months  effort  over  a  duration  of  seven  months,  totaling 
$1,290,569. 
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2,  Software  Engineering 

The  “System  Size”  and  “System  Cost  Driver”  attributes  of  the  COCOMO  II 
estimation  methodology  required  numerous  variables  be  explored  and  defined.  This 
section  iteratively  explored  each  variable,  its  relation  to  DSHEL,  and  each  rationale  as  to 
the  selection  for  its  attribute  ranking  based  on  the  accepted  disposition  definitions  from 
the  SE  Cost  Estimation  Workbook  (Madachy,  Systems  Engineering  Cost  Estimation 
Workbook  2014). 

A  candidate  for  software  use,  based  on  the  functional  requirements  of  DSHEE, 
was  performed  assessing  the  ability  to  satisfy  the  needs  of  the  four  pillars  of  DS  under 
evaluation.  In  accordance  with  the  DOD  Memorandum  regarding  free  open  source 
software  (EOSS)  (Department  of  Defense  Chief  Information  Officer  2009),  EOSS 
solutions  were  initially  evaluated  over  COTS  solutions,  as  mandated  by  this  memo.  The 
fundamental  functions  used  in  the  private  sector  when  evaluating  this  type  of  software 
falls  into  the  realm  of  information  technology  (IT)  system  monitoring  tools.  This  is  an 
important  factor  to  recognize  that  DSHEE,  can  be  met  with  the  100%  reuse  of  existing 
COTS  or  EOSS  simply  by  providing  the  data  in  industry  standard  formats  (e.g.  SNMPvS, 
IPMI,  etc.).  Closed  source  COTS  solutions,  such  as  Splunk  Enterprise  (Splunk  Inc.)  or 
Solarwinds  (Solarwinds  Inc.),  provide  this  functionality  for  service  engineers  to  remotely 
monitor  data  centers,  computing  equipment,  and  environmental  controls.  After 
performing  an  AoA,  EOSS  alternative  solutions  were  determined  to  be  feasible:  Nagios 
(Nagios  Organization),  Spiceworks  (Spiceworks  Inc.),  and  Zabbix  (Zabbix  Inc.).  The 
needs  of  this  COCOMO  II  estimate  required  ease  of  access  to  source  code  for  analysis 
alongside  little  to  no  engineering  integration  involved  (for  the  purposes  of  SEOC  count). 
Nagios  was  chosen  as  the  candidate  for  analysis.  This  was  due  to  it  having  the  highest 
adoption  for  use  by  the  open  source  community,  available  documentation,  and  the  source 
code  for  its  core  application  and  plugins  were  available  without  need  to  manually 
integrate.  The  latter  options,  Spiceworks  and  Zabbix,  had  drawbacks  in  that  Spiceworks 
was  recently  acquired  by  a  private  company;  thereby  ending  its  continued  development 
and  the  availability  of  usage.  The  documentation  for  Zabbix  was  limited.  The  UCC  tool 
(v2013.4)  was  then  used  to  perform  an  analysis  on  the  Nagios  Core  application  v4.0.8 
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and  the  Nagios  Plugins  v2.0.3  somce  code.  The  results  are  displayed  in  Table  22  and 
Table  23. 


Table  2 1 .  UCC  Analysis  Output  for  Nagios  C ore  v4 . 0 . 8 


Language  Name 

Number  of  Files 

Physical  SLOC 

Logical  SLOC 

Bash 

3 

4767 

3835 

CCPP 

188 

93681 

72257 

CSS 

35 

1273 

3252 

JavaScript 

2 

529 

514 

Makefile 

1 

5 

5 

Peri 

16 

1586 

1417 

Ruby 

1 

95 

76 

PHP 

12 

815 

632 

HTML 

7 

600 

340 

Total 

265 

103351 

82328 

Table  22.  UCC  Analysis  Output  for  Nagios  Plugins  v2.0.3 


Language  Name 

Number  of  Files 

Physical  SLOC 

Logical  SLOC 

Bash 

4 

7319 

5919 

C CPP 

222 

59702 

37841 

Makefile 

2 

1400 

1247 

Peri 

13 

3013 

2207 

Total 

241 

71434 

47214 

The  tool  output  categorized  the  various  software  languages  used  in  the  soiuce 
code  and  provided  metrics  on  actual  number  of  files,  alongside  physical  and  logical 
SLOC.  For  the  purposes  of  this  analysis,  Physical  SLOC  can  be  ignored  as  it  is  not  used 
in  the  COCOMO  n  methodology;  it  applies  only  to  traditional  COCOMO  where 
programmer  comments,  blank  lines,  and  white  spaces  are  coimted.  These  provide  no 
fimctional  value  to  code  execution;  therefore,  the  improvements  of  COCOMO  n  only 
logical  SLOC  (lines  of  code  executed  by  the  computer)  were  coimted  for  this  this  cost 
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estimation  in  accordance  with  the  guidelines  set  by  the  Software  Engineering  Institute 
(SEI).  Adding  the  resulting  logical  SEOC  analysis  results  together,  gave  a  reuse  estimate 
of  129,542  source  lines  of  code. 

The  “Integration  Required”  refers  to  the  amount  of  effort  necessary  to  adapt  the 
DSHEE  software  into  its  environment  and  test  the  product  compared  to  the  normal 
amount  of  integration  and  test  effort  for  software  of  a  comparable  size.  Given  the 
application  chosen  not  only  meets  the  requirements  of  DSHEE,  but  has  very  few 
additional  features  not  required  in  the  plugins  package,  the  amount  of  integration  and  test 
is  comparable  to  a  full  IT  monitoring  suite.  Given  the  available  plugins  with  Nagios  and 
the  ones  selected  for  DSHEE  implementation,  the  Integration  Required  was  estimated  to 
be  90%. 

The  reuse  “Assessment  and  Assimilation”  refers  to  the  effort  required  when 
determining  if  a  fully  reused  DSHEE  software  merits  use  to  the  application  and  if  it  is 
required  to  integrate  its  description  into  the  overall  HEE  product  description.  Given  there 
would  be  considerable  module  test  and  evaluation  alongside  additional  documentation  to 
adapt  to  HEE,  the  assessment  and  assimilation  effort  was  rated  at  6%. 

The  “Precedentness”  of  the  software  describes  the  degree  to  which  past 
experience  applies  for  project  execution,  coupled  with  the  relative  age  of  the  system. 
While  the  software  chosen  is  widely  used  in  the  private  sector  and  years  of  experience 
exist  with  IT  System  monitoring  applications,  the  application  to  naval  weapon  systems  is 
only  generally  familiar  given  the  usage  of  DS.  Given  this  is  familiar  to  several  previously 
developed  naval  PoRs,  there  is  little  need  for  the  development  of  processing  algorithms, 
and  there  exists  a  large  organizational  understanding  of  the  DS  objectives  in  the  USN 
enterprise.  The  precedentedness  was  determined  to  be  high. 

“Development  Elexibility”  is  the  need  for  the  software  to  conform  to  specific 
requirements.  Since  the  external  interfaces  specifications  are  modeled  on  known  open 
standards  such  as  TCP/IP  and  SNMPvS  for  modem  IEEE  reporting  standards,  alongside 
the  complete  reuse  of  the  application  where  only  network  configuration  is  necessary  for 
basic  interface,  the  Development  Elexibility  was  determined  to  be  extra  high. 
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“Architecture  and  Risk  Resolution”  covers  the  degree  of  design  thoroughness  and 
risk  elimination.  Given  this  study  has  provided  the  DS  framework,  initial  design,  risk 
identification  and  mitigation  paths  for  the  identified  2-4  critical  risk  items,  as  well  as  a 
strong  familiarity  of  the  shipboard  architecture;  the  rating  was  determined  to  be  nominal. 

“Stakeholder  Team  Cohesion”  defines  how  well  a  team  collaborates.  Future 
inputs  to  stakeholder  team  cohesion  will  most  likely  consist  of  NAVSEA,  SPAWAR, 
ONR,  and  industry  partners.  The  team  is  composed  of  personnel  from  similar 
organizations,  share  project  culture,  compatible  organizational  objectives,  and  clear  roles 
and  responsibilities  as  defined  by  the  warfare  center  technical  capabilities.  Therefore, 
cohesion  was  determined  to  be  nominal. 

The  “Process  Maturity”  describes  the  consistency  and  effectiveness  of  the  project 
team  performing  the  SE  processes.  Given  the  current  industry  and  government  HEE 
teams  have  defined  SE  processes,  activities  driven  by  benefit  to  the  project,  a  process 
approach  driven  by  the  organizations  involved,  as  well  as  a  CMMI  assessment  level  of  3, 
this  is  synonymous  with  a  high  process  capability  per  the  Cost  Estimation  Workbook. 

The  “Required  Software  Reliability”  refers  to  the  extent  at  which  it  must  perform 
its  intended  DS  function  over  time  and  the  impact  to  operations  and  safety,  if  a  failure 
occurs.  DSHEE  is  a  maintenance  IT  System  supporting  HEE.  The  event  of  DSHEE 
system  failure  would  cause  a  person  technical  assistance  to  recover  however  the  HEE 
would  continue  to  operate.  While  this  has  a  financial  impact  from  in  person  travel,  the 
loss  is  only  moderate  easily  recoverable.  Therefore,  the  required  software  reliability  was 
determined  to  be  nominal. 

The  “Data  Base  Size”  is  an  important  factor  to  consider  when  performing  a  cost 
estimate  for  an  application  such  as  DSHEE.  The  rating  is  a  logical  comparison  of  the 
potential  data  base  size  to  the  existing  SEOC  count.  This  mainly  focuses  and  drives  the 
cost  of  test  and  evaluation,  given  the  effort  to  generate  the  test  data  to  exercise  DSHEE 
and  save  results.  Given  the  data  base  would  have  simulated  input  alongside  the  saved 
sensor,  health  status,  and  maintenance  results  of  HEE,  the  data  base  would  be  quite  large 
in  bytes.  Given  an  average  data  base  record  with  twelve  fields  results  in  a  storage  size  of 
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50  bytes,  alongside  a  typieal  Navy  Core  Test  (NCT)  stress  test  seenario  with  5000 
simulated  inputs,  the  estimated  data  base  size  would  then  be:  3  data  types  (sensor,  health, 
maintenanee)  *  5000  input  records  *  50  bytes/record  +  3  data  types  *  5000  result  records 
*  50  bytes/record  =1.5  Megabytes  of  data.  The  ratio  of  bytes  in  the  database  to  SLOC  is 
then  1,500,000  /  129,542  resulting  in  a  ratio  factor  of  approximately  12.  By  the 
COCOMO  II  assessment  scale,  this  resulted  in  a  data  base  size  rating  of  nominal. 

The  “Product  Complexity”  of  DSHEL  was  assessed  across  five  main  areas: 
control  operations,  computational  operations,  device  dependent  operations,  and  user 
interface  management  options.  Since  the  code  is  100%  reuse,  the  complexity  of 
development,  aligns  with  control  operations  having  straight  line  code  with  few  non¬ 
nested  operations.  The  device  dependent  operations  have  status  checking  of  the  HEL 
components,  with  moderately  complex  database  operations  for  database  queries  and  the 
user  interface  management  options  are  provided  with  pre  built  dashboards  with  the  option 
of  using  simple  graphical  user  interface  builders.  The  Product  Complexity,  given  a 
variety  across  the  main  areas  of  assessment,  therefore  was  determined  to  be  low. 

“Development  for  Reuse”  cost  drivers  account  for  the  additional  effort  during 
acquisition  such  that  DSHEE  can  be  reused  across  other  HEE  platforms.  Given  the 
software  itself  is  fully  reused  from  another  project,  the  effort  is  inherently  low.  However, 
careful  design  in  architecture  must  be  observed  such  that  the  DSHEE  subsystem  itself  can 
be  reused  in  future  mods  or  HEE  baselines.  The  reusability  aspect  was  determined  to  be 
nominal,  as  the  reuse  design  architecture  was  inherent  from  the  initial  components  of 
DSHEE. 

Eogistics  artifacts  such  as  documentation,  formality,  and  necessary  detail  required 

for  delivery  of  the  DHSEE  component,  must  be  considered  when  taking  the  life-cycle 

support  into  account.  While  standard  NAVSEA  Eogistics  Center  requirements  mandate 

rigorous,  strict  standards  and  requirements,  the  detail  necessary  to  guide  the  users  through 

DS  processes,  must  also  leverage  large  amounts  of  documentation  which  are  more 

rigorous  relative  to  the  life-cycle  needs.  This  is  due  to  the  cybersecurity  concerns  and 

adherence  to  process  compliance  for  necessary  man-in-the-loop  operations  of  DS.  In  turn, 

this  leads  the  documentation  assessment  to  be  very  high 
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“Analysts  Capability”  refers  to  those  personnel  responsible  for  requirements,  high 
level  design,  and  detail  design.  This  has  overlap  with  the  SE  capability  also  performing 
very  similar  efforts.  Given  that  the  field  of  DS,  infrastructure,  and  naval  engineering  is 
competent  with  SE,  this  was  determined  to  be  at  least  in  the  75th  percentile,  leading  to  an 
assessment  of  high. 

The  “Programmer  Capability”  describes  the  ability,  efficiency,  and  thoroughness 
of  the  software  engineering  alongside  communication  and  cooperation  skillsets.  Given 
the  code  is  reused,  Nagios  is  widely  known  and  used  by  the  IT  Administrator  community, 
and  the  software  only  required  modification  to  the  configuration  of  the  HEE  system  for 
SNMP  traps  alongside  the  shipboard  infrastructure  configuration  for  email  and  chat 
server  IP  addresses,  the  assessment  rating  was  determined  to  be  in  the  90th  percentile  at 
very  high. 

“Personnel  Continuity”  relate  to  the  applicability  and  consistency  of  the  staff  at 
the  initial  stage  of  the  project,  with  respect  to  the  system  domain,  customer,  user,  and 
technology.  Given  the  pool  of  naval  IT,  infrastructure,  and  systems  engineers  who  have 
already  been  in  the  test  bed  development  stage  of  HEE,  alongside  the  existence  functional 
resources  within  the  warfare  centers,  it  is  assumed  there  would  at  least  be  three  years 
continuous  experience  available  on  average,  and  a  turnover  of  less  than  12%.  Therefore, 
the  continuity  was  determined  to  be  nominal. 

“Application  Experience”  relates  to  the  level  of  experience  of  the  team 
developing,  or  in  the  case  of  DSHEE  software  reuse,  application  configuration  and 
installation  in  terms  of  the  software  subsystem.  Given  the  DSHEE  personnel 
requirements  for  cybersecurity  workforce  and  information  technology  engineers,  the  team 
can  assume  to  have  application  experience  of  at  least  three  years  to  meet  the  project 
needs,  which  led  to  an  application  experience  of  high. 

“Platform  Experience”  relates  to  the  applicability  and  consistency  of  the  staff  at 
the  initial  stage  of  the  project,  with  respect  to  the  system  domain,  customer,  user,  and 
technology.  Given  the  pool  of  DE  and  naval  systems  engineers  who  have  already  been 
involved  on  the  development  stage  of  maritime  HEE  systems  would  also  be  involved  in 
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the  development  of  the  DSHEL  component,  it  is  estimated  by  the  time  DSHEL  would  be 
integrated  there  would  at  least  be  three  years  continuous  experience  available  on  average, 
leading  to  an  assessment  of  high. 

“Eanguage  and  Toolset  Experience”  describes  the  measure  of  the  software 
application  experience  of  the  team  developing  the  DSHEE  subsystem.  It  includes  the  use 
of  tools  that  perform  requirements  and  design  representation  and  analysis,  configuration 
management,  document  extraction,  library  management,  program  style  and  formatting, 
consistency  checking,  planning  and  control.  Given  these  type  of  system  design  tools  and 
remote  monitoring  applications  common  to  those  within  the  naval  software  engineering 
community  and  IT  infrastructure  domain,  the  language  and  toolset  experience  was 
assessed  to  be  very  high. 

The  execution  “Time  Constraint”  refers  to  the  measure  of  limitation  imposed  on 
the  reactiveness  and  execution  of  the  software  application.  Given  this  is  a  system  status 
and  maintenance  reporting  system,  not  affecting  the  performance  of  the  HEE,  the 
execution  Time  Constraint  was  assessed  to  be  nominal  given  neither  real  time  nor  near- 
real  time  execution  is  required  for  DSHEE. 

The  “Storage  Constraint”  parameter  describes  the  limits  on  storage  of  data  in 
memory  or  hard  drive  of  the  system.  Given  the  cost  of  storage  has  dropped  dramatically 
to  where  a  stock  computing  storage  device  measured  in  multiples  of  terabytes  costs  less 
than  $100  in  EY14,  alongside  the  already  estimated  database  size  of  storing  records  being 
far  less,  the  main  Storage  Constraint  was  conservatively  estimated  to  be  less  than  70% 
usage  of  the  available  storage  leading  to  an  assessment  of  high. 

The  “Platform  Volatility”  of  DSHEE,  in  terms  of  software,  refers  to  the  relative 
frequency  of  change  with  respect  to  operating  system,  computing  hardware,  and  HEE 
system  under  monitoring.  Given  the  acquisition  focus  of  naval  weapons  is  to  develop  and 
freeze  a  baseline  for  multiple  years  in  terms  of  system  stability,  the  amount  of  change  is 
measured  to  be  greater  than  a  major  change  every  year  with  a  minor  change  monthly.  At 
most,  the  Platform  Volatility  in  terms  of  the  COCOMO  II  time  constraints  was  assessed 
to  be  low. 
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The  “Use  of  Software  Tools”  for  DSHEL  development  describes  the  rating  of 
simple  tools  for  purposes  of  simple  edits  to  coding  and  life-cycle  management  tools. 
Given  the  tools  for  editing  the  selected  FOSS  are  readily  available  (e.g.  Eclipse  integrated 
development  environment  and  subversion  (SVN)  configuration  management  version 
control  software)  and  are  well  integrated  with  controlled  processes  and  methods,  the  use 
of  software  tools  was  assessed  to  be  very  high. 

“Multisite  Coordination”  on  a  USN  project  is  an  area  that  covers  the  location  of 
stakeholders,  team  members,  resources,  and  corporate  collaboration  barriers.  Given  the 
naval  warfare  centers,  research  labs,  program  offices,  and  test  sites  span  the  reaches  of 
the  country  this  leads  to  a  team  which  is  remotely  collaborating  at  times.  However,  given 
criteria  defined  by  the  Cost  Estimation  Workbook  as  usage  of  wideband  electronic 
communication,  Internet  based  teleconference,  and  interactive  development  environments 
which  employ  collaborative  tools  and  processes  in  place  to  mitigate  these  barriers,  the 
coordination  effort  averages  out  to  an  assessment  of  high. 

The  “Required  Development  Schedule”  constraint  refers  to  the  measure  of 
limitation  imposed  on  the  development  of  the  software  application.  It  is  a  percentage  ratio 
of  schedule  with  respect  to  the  nominal  project  length,  or  rather  the  available  schedule  to 
the  nominal  schedule.  Given  the  initial  PoR  fielding  aims  to  the  FY18  timeframe  and  the 
DSHEE  software  reuse  efforts  are  relatively  executable  in  the  next  four  years  (FY14- 
FY18),  the  normal  execution  of  this  effort  would  only  take  1-2  person  years  at  most.  This 
is  approximately  130-150%  of  the  available  execution  time  is  estimated  to  be  needed  for 
completion  before  HEE  is  fielded.  The  execution  time  constraint  was  assessed  to  be  high. 

For  consistency  of  other  distance  support  cost  benefit  studies  performed,  the  labor 
rate  was  assumed  to  be  burdened  approximately  $10,000  per  person  month.  This 
assumption  was  made  for  the  reuse  of  Fleet  technical  assistance  data  and  describes  the 
average  cost  of  technical  assistance  with  and  without  distance  support,  thereby 
normalizing  the  person  hours  used  between  this  DSHEE  estimates  and  existing  Fleet 
data. 
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Table  23  summarizes  the  input  variables  determined  from  the  former  analysis  and 
was  used  as  input  to  the  COCOMO  n  tool,  as  well  as  the  resultmg  estimation  output  in 
Figirre  99  and  Figme  100. 


Table  23.  COCOMO  n  Tool  Input  Data 


Methodology  Variable 

Value 

Software  Size  -  New  Source  Lines  of  Code  (SLOC) 

0 

Software  Size  -  Modified  Soiuce  Lines  of  Code  (SLOC) 

0 

Software  Size  -  Reused  Somce  Lines  of  Code  (SLOC) 

129,542 

Software  Size  -  Reused  %  Integration  Reqirued 

90% 

Software  Size  -  Reused  Assessment  and  Assimilation 

6% 

Software  Scale  Drivers  -  Precedentedness 

HIGH 

Software  Scale  Drivers  -  Development  Flexibility 

EXTRA  HIGH 

Software  Scale  Drivers  -  Architectiu  e  /  Risk  Resolution 

NOMINAL 

Software  Scale  Drivers  -  Team  Cohesion 

NOMINAL 

Software  Scale  Drivers  -  Process  Matmity 

HIGH 

Software  Cost  Drivers  Product  -  Required  Software  Reliability 

NOMINAL 

Software  Cost  Drivers  Product  -  Database  Size 

NOMINAL 

Software  Cost  Drivers  Product  -  Prodirct  Complexity 

LOW 

Software  Cost  Drivers  Product  -  Developed  for  Reirsability 

NOMINAL 

Software  Cost  Drivers  Product  -  Docimientation  to  Life-cycle  Needs 

VERY  HIGH 

Software  Cost  Drivers  Personnel  -  Analyst  Capability 

HIGH 

Software  Cost  Drivers  Persormel  -  Programmer  Capability 

VERY  HIGH 

Software  Cost  Drivers  Persormel  -  Persormel  Continuity 

NOMINAL 

Software  Cost  Drivers  Persormel  -  Application  Experience 

HIGH 

Software  Cost  Drivers  Persormel  -  Platform  Experience 

HIGH 
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Methodology  Variable 

Value 

Sofhvaie  Cost  Drivers  Personnel  -  Language  and  Toolset  Experience 

VERY  HIGH 

Software  Cost  Drivers  Platfonn  -  Time  Constraint 

NOMINAL 

Software  Cost  Drivers  Platfonn  -  Storage  Constraint 

HIGH 

Software  Cost  Drivers  Platfonn  -  Platfonn  Volatility 

LOW 

Software  Cost  Drivers  Project  -  Use  of  Software  Tools 

VERY  HIGH 

Software  Cost  Drivers  Project  -  Multi  Site  Development 

HIGH 

Software  Cost  Drivers  Project  -  Required  Development  Schedule 

HIGH 

System  Labor  Rates 

$10000/ 

Month 
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Expert  COSYSMO  -  Systems  Engineering  Cost  Model  Risk  Advisor 
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Figure  99.  COCOMO  II  Data  Input 
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Results 


Software  Development  (Elaboration  and  Construction) 

Effort  =  45.2  Person-months 
Schedule  ■  16.8  Months 
Cost  =  S452246 


Total  Equivalent  Size  =  42748  SLOC 


Acquisition  Phase  Distribution 


Phase 

Effort 

1  Person- 
months: 

Schedule 

(Months: 

Average 

Staff 

Cost 
:  Oolars) 

incectKXi 

2.7 

2.1 

1.3 

5271 35 

Elaboration 

10.9 

6.3 

1.7 

SI 08539 

Corstructior 

34.4 

10.5 

3.3 

5343707 

T  ransition 

5.4 

2  1 

2.6 

554270 

People 
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Phase/Actrvitv 
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T  ransition 

Management 

0.4 

1.3 

3.4 

0.8 

Envronment/CM 

0.3 

0.9 

1.7 

0.3 

Requirements 

1.0 

2.0 

2.7 

0.2 

Design 

0.5 

3.9 

5.5 

0.2 

Implementation 

0.2 

1.4 

11.7 

1.0 

Assessment 

0.2 

1.1 

8.2 

1.3 

DeplO'/Tnent 

0.1 

0.3 

1.0 

1.6 

Figure  100.  COCOMO  II  Data  Analysis  Results 


Based  on  the  resulting  analysis,  it  was  estimated  that  the  total  Software 
Engineering  effort  during  acquisition  would  be  45.2  person  months  effort  over  a  duration 
of  16.8  months,  totaling  $452,246. 

3,  Hardware  Engineering 

The  hardware  engineering  material  cost  was  a  straightforward  identification  of 
computing  resources  necessary  to  meet  shipboard  environment  and  DSFIEL  functional 
requirements. 

The  main  host  of  the  DSHEE,  an  86x64  bit  architecture  computer,  was  evaluated 
in  comparison  to  existing  AEGIS  Combat  System,  DDG  and  CG  ISNS,  and  Eittoral 
Combat  Ship  Total  Ship  Computing  Environment  (TSCE)  computing  systems.  The  basic 
server  meeting  the  shipboard  grade  B  environmental  shock  and  computing  resource 
requirements  for  Red  Hat  Enterprise  Linux,  as  well  as  the  associate  IT  monitoring 
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application  software,  was  identified  as  a  Hewlett  Paekard  HPDL320.  The  assumption  to 
use  existing  COTS  already  in  use  on  USN  PoRs  is  that  the  platform  is  already  proven 
viable  in  the  operational  environment  as  well  as  to  minimize  developmental  logistics 
costs  of  the  USN  supply  system,  provisioning,  teeh  manuals,  etc.  Based  on  market  eost  of 
the  USN  supply  system,  a  standard  eonfiguration  of  the  HPDL320  had  an  average  cost  in 
FY15  dollars  of  $1,500. 

The  seeondary  human  systems  integration  interfaee,  whieh  remotely  extends  the 
maintenanee  eonsole  of  the  afloat  HEL,  via  DSHEL,  to  the  ashore  support  engineer  is  an 
Internet  protoeol  based  keyboard  video  and  mouse  switeh  (IKVM).  When  aeeess  is 
permitted  by  the  shipboard  operators,  IKVM  works  by  taking  the  digital  signals  used 
from  operator  input  and  provide  a  seeure  enerypted  TCP/IP  interfaee  via  the  GIG  sueh 
that  an  operator  ean  remotely  login  and  troubleshoot  a  system.  An  evaluation  of  IKVMs 
in  eomparison  to  existing  USN  KVM  switehes  in  the  supply  system  was  made.  The  basie 
IKVM  meets  seeurity  and  funetional  requirements  of  DSHEE  as  identified  by  Raritan 
Dominion  KX  III.  The  same  assumption  was  used  by  existing  COTS  equipment  in  use  on 
USN  PoRs.  These  platforms  have  already  proven  viable  in  the  operational  environment 
as  well  as  to  minimize  developmental  logistics  costs  of  the  USN  supply  system, 
provisioning,  and  teeh  manuals.  Based  on  market  eost  of  the  USN  supply  system,  a 
standard  eonfiguration  of  the  IKVM  had  an  average  eost  in  PY15  dollars  of  $2,000. 

The  amount  of  data  eollected  regarding  sensors,  system  health,  and  BIT  results 
require  a  large  supply  of  available  data  storage.  A  typieal  eonfiguration  for  this  is  a  set  of 
hard  drives  using  a  Redundant  Array  of  Independent  Disks  (RAID)  eonfiguration.  RAID 
is  a  teehnology  whieh  provides  extended  reliability,  availability,  and  maintainability  for 
IT  systems  by  independently  ereating  baekups  of  data  stored  aeross  multiple  hard  drives. 
In  essenee,  failures  ean  oeeur  without  impaet  to  operations  or  loss  of  data.  Teehnology 
sueh  as  RAID  bundled  in  a  network  storage  deviee  is  known  as  Network  Attaehed 
Storage  (NAS).  COTS  NAS  deviees  exist  in  eommon  use  aeross  the  USN  enterprise  and 
a  eomponent  eommon  to  naval  weapon  and  eombat  systems  is  the  Hewlett  Paekard  Store 
Easy  1600  NAS.  Based  on  market  eost  of  the  USN  supply  system,  a  standard 
eonfiguration  of  the  HP  NAS  had  an  average  eost  in  PY15  dollars  of  $10,000. 
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Given  the  ciment  test  bed  application  of  HEL  has  yet  to  reach  program  of  record 
status  or  develop  a  HEL  fielding  plan,  an  assumption  was  made  for  producing  the  a  cost 
estimate  in  terms  of  DSHEL  development.  The  DDG,  CG,  and  ECS  platforms  have  been 
iderrtifred  for  firtirre  HEL  employment.  Therefore,  a  conservative  estunate  of  10  HEL  per 
ship,  resirlting  in  10  DSHEL  per  ship,  alongside  an  additional  system  at  the  HEL  land 
based  test  site  was  assimied.  An  estimate  of  miscellaneous  parts  necessary  for  installation 
(e.g.,  bracketing,  cables,  screws)  was  estimated  at  $2,000.  To  overcome  defective  imits 
which  fail  prior  to  their  MTBF,  arr  initial  sparing  of  20%  of  the  total  30  DSHEL  was 
assumed,  acquiring  arr  additional  six  imits.  No  spare  units  were  assumed  to  be  prociued 
for  the  land  based  test  site  as  this  is  normal  practice  given  the  negligible  impact  to 
shipboard  operations.  As  with  the  production  of  any  system,  hardware  costs  dimmish 
with  a  marginal  benefit  per  imit  produced  and  this  should  be  taken  into  accoimt  when  an 
actiral  fielding  plan  exists  for  HEL.  The  hardware  cost  estimate  is  indicated  in  Table  24 
and  Table  25. 


Table  24.  DSHEL  Hardware  Parts  Breakdown  Estimate 


DSHEL  Components 

Cost 

Quantity 

Total  Cost  Per 

HEL 

Computer  Server 

$1,500 

1 

$1,500 

Network  Attached  Storage 

$10,000 

1 

$10,000 

iKVM 

$2,000 

1 

$2,000 

Install  Misc  (brackets,  cables) 

$2,000.00 

1 

$2,000 

$15,500 
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Table  25.  DSHEL  Total  Estimate  Based  on  Number  of  HEL  Sites  and  Spares 


Ship  Platform  Types 

HEL 

Quantity 

Initial  Sparing 
(20%) 

Total 

DSHEL 

Total 

DSHEL  HW  Cost 

DDG 

10 

2 

12 

$186,000 

CG 

10 

2 

12 

$186,000 

LCS 

10 

2 

12 

$186,000 

Land  Based  Test  Site 

1 

0.2 

1 

$15,500 

$573,500 

Based  on  the  resulting  analysis,  it  is  estimated  the  total  DSHEL  COTS  Hardware 
Engineering  effort  dining  acquisition  would  be  a  material  cost  of  $573,500. 

4.  Sustainment  Engineering 

For  estimating  the  hardware  cost,  the  aforementioned  sustainment  methodology 
was  applied  taking  in  to  accoimt  obsolescence  management,  engineering  analysis,  as  well 
as  logistics  efforts.  The  cost  of  the  replacement  parts  was  assimied  to  be  equivalent  given 
COTS  successors  are  relatively  the  same  as  the  original  imit.  The  engineering  analysis 
effort  was  assirmed  to  be  two  person-months  at  the  standard  labor  rate  of  $10,000  per 
month.  The  effort  to  perform  regression  testing,  logistics  artifact  irpdates,  and  change 
control  review  with  configuration  management  were  also  assumed  to  be  a  person-mouth 
eqirally.  Given  the  cost  analysis  only  focuses  on  the  DSHEL  component  of  HEL,  it  can 
be  assumed  similar  obsolescence  management  efforts  are  occiuiing  in  parallel  with  HEL; 
thereby  leveraging  the  shipboard  hardware  installation  and  checkout  activities  as  a  sunk 
cost  which  occius  with  or  without  the  presence  of  DSHEL.  The  assumed  service  life  of 
HEL  was  also  assumed  to  be  consistent  with  the  normal  20  year  system  life  span;  life- 
cycle  occimences  of  this  effort  are  the  number  of  times  the  event  would  occin  between 
transition  and  retirement.  The  hardware  sustainment  cost  estimate  is  shown  in  Table  26. 
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Table  26.  DSHEL  Siistaimiient  Hardware  Estimate 


Hardware 

Cost 

Qty. 

Life-cycle 

Occurrences 

Total 

Computer  Server  Obsolescence 

$1,500 

37 

3 

$166,500 

NAS  Spares  and  Obsolescence 

$10,000 

37 

3 

$1,110,000 

iKVM  Switch  Obsolescence 

$2,000 

37 

3 

$222,000 

HW  Obsolescence  Analysis  Effort 

$20,000 

1 

3 

$60,000 

HW  Regression  Testing 

$10,000 

1 

3 

$30,000 

HW  ILS  Artifact  Updates 

$10,000 

1 

3 

$30,000 

HW  ECP  Review  and  Configiuation 
Mgiut. 

$10,000 

1 

3 

$30,000 

$1,648,500 

For  estimating  the  software  cost,  the  aforementioned  sustauiment  methodology 
was  applied,  taking  in  to  accoimt  the  software  license  management  efforts  of  the 
operating  system,  engineering  analysis,  regression  testing,  as  well  as  logistics  efforts. 
Given  the  FOSS  application  chosen,  Nagios,  is  rrative  to  the  Linirx  platform.  Red  Hat 
Enterprise  Linirx  (RHEL)  was  assumed  as  the  operating  system  employed  on  DSHEL  as 
is  standard  with  most  Linirx  based  USN  PoRs.  The  software  license  is  a  one  time  or 
reciuiing  usage  fee  for  OSs  and  applications.  RHEL  uses  a  subscription  based  license  for 
expedited  seciuity  and  ftmctioual  system  patches.  RHEL  is  open  somce  to  use  given  it  is 
FOSS.  The  subscription  is  paying  for  support  which  is  mandated  in  order  to  maintain  a 
seciuity  accreditation.  The  armiial  price  assumed  was  that  of  the  commercial  sector  for 
extended  support,  $1,300  a  year  per  installation  (shipboard  and  lab).  It  is  fan  to  note 
government  pricing  and  volume  pmchases  decrease  the  price;  however,  that  is  a 
contractual  agreement  between  the  government  and  Red  Hat,  beyond  the  scope  and 
distribution  disclosine  of  this  paper.  Therefore,  the  flat  private  sector  price  was  assumed 
for  input.  Similarly,  for  the  VMWare  virtualization  platform  ESXi  hypervisor,  the 
licensing  costs  are  determined  per  version  per  core  of  the  HPDL320  server.  Given  the 
HPDL320  has  foin  cores,  at  a  licensing  cost  of  $2000  per  core;  the  cost  per  DSHEL  is 
$8,000.  Regression  testing,  engineering  change  proposal  development  and  review, 
alongside  configiuation  management  and  logistics  processes  necessary,  were  all  assumed 
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to  be  a  person-month  each.  It  was  assmned  that  since  the  ship  platfoims  with  the  ISNS, 
CANES,  and  TSCE  infiastnictiues  aheady  provide  workstations  to  enable  email  and 
chat,  that  DSHEL  would  inherit  this  infiastnictme  service  and  not  have  to  additionally 
install  Microsoft  Windows  to  satisfy  these  requhements.  The  cost  was  then  applied 
towards  the  30  shipboard  mstallations  of  DSHEL  and  the  single  land  based  test  site.  It 
was  assirmed  that  modem  web  based  patch  distribrrtion  via  the  GIG  shall  be  leveraged  for 
DSHEL  patch  installation  and  irpdate.  Sailor  2.0,  a  system  managed  by  SPAWAR 
Systems  Center  (SSC)  Pacific,  is  irsed  for  many  applications  in  which  patches  are 
downloaded  and  installed  by  the  shipboard  crew  Information  Technology  Chief  (ITC)  or 
Fue  Controhnarr  Cliief  (FCC)  to  avoid  physical  visits  by  the  ISEA  or  SSA  for 
installation.  The  assirmed  service  life  of  HEL  was  also  assirmed  to  be  consistent  with  the 
normal  20-year'  system  life  span.  Life-cycle  occiurences  of  this  effort  ar  e  life  span  driven 
by  the  necessary  annual  renewal  of  licenses  or  required  patch  update  periodicity.  The 
periodicity  of  life-cycle  occimences  for  softwar  e  differs  from  hardware,  in  that  software 
licenses  occiu'  annually  and  patching  occms  serni-armually.  Therefore,  the  quantity 
represents  how  many  times  a  year  the  event  occms,  not  including  the  initial  year'  wliich 
transitions  to  operation  or  the  disposal  year.  While  RHEL  OS  licensmg  costs  occm 
annually  resulting  in  18  life-cycle  occiuiences,  the  VMWare  ESXi  licenses  are  perpetual 
imtil  a  major  version  upgrade.  The  assumed  software  tech  mseilion  refresh  is  then  once 
ever'y  year  for  VMWare,  resulting  in  six  life-cycle  occimences.  The  software  sustainment 
cost  estimate  is  shown  in  Table  27. 


Table  27.  DSHEL  Sustainment  Software  Estimate 


Softw'are 

Cost 

Qty. 

Life-cycle 

Occurrences 

Total 

Red  Hat  Linux  Software  License  and  Patches 

$1,300 

31 

18 

$806,000 

VMWare  eSXI  License  and  Patches 

$8,000 

31 

6 

$1,488,000 

SW  Update/Patch  Regression  Testing 

$10,000 

2 

18 

$400,000 

SW  Update/Patch  ILS  Artifact  Updates 

$10,000 

2 

18 

$400,000 

SW  ECP  Review  and  Configmation  Mgmt 

$10,000 

2 

18 

$400,000 

$3,293,400 
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In  siimmaiy,  the  total  hardware  sustaimnent  costs  of  $1,648,500  and  software 
sustainment  costs  of  $3,293,400  result  in  an  aggregate  DSHEL  sustainment  cost  of 
$4,941,900  over  the  20-year  service  life,  captiued  in  FY15  dollars. 

5.  Life-Cycle  Cost  Benefit  Analysis 

Tying  together  the  aforementioned  estimates,  the  pmpose  of  this  section  is  to 
sunnnarize  the  costs  associated  with  the  acquisition  and  sustainment  of  DSHEL.  This 
estimate  describes  the  DSEDEL  life-cycle  cost  to  the  HEL  program  and  deteimines  the 
breakeven  point  in  which  DSHEL  “pays  for  itself” 

Incorporating  the  previous  results  fiorn  modeling  and  simulation,  it  was 
determined  that  the  average  downtime  of  a  system  with  no  distance  sirpport,  the  “statirs 
quo”  methodology,  was  six  days.  Downtune  associated  with  the  use  of  a  DSHEL 
comporrent  resulted  nr  an  estimate  of  two  days.  Using  the  cost  estimates  associated  with 
technical  assistance,  an  approximatiorr  carr  be  made  on  the  cost  per  event.  The  statrrs  quo 
methodology  rrses  common  DOD  brrdgeting  place  holders  for  $5,000  per  person,  per 
week  for  OCONUS  travel  to  accoimt  for  aufare  and  hotel.  A  trormal  work  day  of  eight 
person  horns  can  be  assumed  druing  each  day  of  system  downtime.  On  average,  two  in 
serwice  engineering  agents  are  sent  on  site  to  provide  assistance,  typically  a  hardware  and 
software  srrbject  matter  expert.  By  multiplying  the  irrrmber  of  days  of  downtime,  by  eight 
horns  per  day,  by  the  nirmber  of  people,  and  firrally  adding  the  travel  cost  per  person,  an 
estimate  per  cost  of  technical  assistance  can  be  made.  Tliis  estimate  was  then  performed 
on  the  modeling  and  simulation  results  in  Table  28. 


Table  28.  M&S  Downtime  Cost  per  Technical  Assistance  Estimate 


Tech  Assist 
Type 

Downtime 

(Days) 

Downtime 
(Work  Hours) 

People 

Travel 

Cost 

Rate 

(S/hr) 

Total 

M&S  with 
DSHEL 

10.47375 

83.79 

1 

$0 

$60 

$5,027 

M&S  with 
Status  Quo 

18.62125 

148.97 

2 

$10,000 

$60 

$18,938 
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Refilling  the  above  estimate,  studies  on  matme  legacy  naval  weapon  systems  have 
been  perfoimed  by  PEO  IWS  in  relation  to  DS  and  the  cost  of  technical  assistance.  The 
cost  savings  of  execution  effort  provided  by  DS  provided  by  this  exteiual  study  (Smith, 
Leonard  and  Jones  2012)  showed  cost  savings  where  the  average  cost  of  per  technical 
assistance  event  is  $1,140  when  integrated  DS  is  employed  and  $15,390  with  status  quo 
assistance.  The  average  cost  was  based  on  a  labor  rate  of  a  $10,000  person  month 
(approx.  $60  per  horn)  biudened  labor  rate  of  onsite  teclmicians  and  in  service  engineers, 
including  travel.  This  data,  while  only  applicable  to  legacy  weapons  systems,  is  being 
mcluded  for  comparison  as  the  M&S  results  are  applied  to  DSHEL  with  the  HEL  POL 
While  the  PEO  IWS  study  provides  valuable  data,  it  was  perfoimed  on  legacy  weapons 
systems,  with  a  large  SME  support  base,  for  systems  which  have  been  deployed  in  the 
Fleet  for  decades.  The  M&S  was  tailored  towards  HEL,  which  is  a  first  of  its  kind 
weapon  system  and  a  smaller  SME  support  base  for  the  USN. 

Table  29  summarizes  the  life-cycle  costs  inider  analysis  for  deteiinining  when  the 
amoimt  of  technical  assistance  requests  reaches  a  point  when  DSHEL  begins  to  pay  for 
itself,  also  known  as  the  “breakeven”  point. 


Table  29.  DSHEL  Life-Cycle  Cost  with  Downtime  Estimate 


Cost  Type 

Total 

DSHEL  Acquisition  Systems  Engineeiing 

$1,290,569 

DSHEL  Acquisition  Software  Engineering 

$452,246 

DSHEL  Acquisition  Hardware  Engmeermg 

$573,500 

DSHEL  Total  Acquisition  Cost 

$2,316,315 

DSHEL  Sustaimnent  Engineering  (SE/SW/HW) 

$4,941,900 

DSHEL  Total  Life-cycle  Cost 

$7,258,215 

DSHEL  Service  Life  (Years) 

20 

Average  DSHEL  Life-cycle  Cost  per  Year- 

$362,911 

M&S  DSHEL  Cost  per  Teclmical  Assistance 

$5,027 

M&S  Status  Quo  Cost  per  Technical  Assistance 

$18,938 

Legacy  DSHEL  Cost  per  Technical  Assistance 

$1,140 

Legacy  Status  Quo  Cost  per  Technical  Assistance 

$15,390 
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By  using  the  known  cost  of  technical  assistance  with  and  without  distance  support 
from  the  M&S  results  in  this  capstone,  as  well  as  the  legacy  PEO  IWS  study  costs  for 
comparison,  the  average  DSHEL  life-cycle  cost  per  year  can  then  be  combined  into  a 
linear  formula  for  predicting  cost  based  on  the  number  of  technical  assistance  requests  by 
the  Elect.  These  results  are  illustrated  in  Figure  101  and  Figure  102. 

M&S  Status  Quo  DS  Cost  (#  Tech  Assists)  =  $18,938  *  (#  Tech  Assists) 


M&S  DSHEL  Cost  Tech  Assists)  =$5,027  *  Tech  Assists)  +  $362,911 


Legacy  Status  Quo  DS  Cost  Tech  Assists)  =$15,390  *  Tech  Assists) 


Legacy  DSHEL  Cost  Tech  Assist)  =  $1,14^0  *  Tech  Assists)  -I- $362,911 


System  Cost  Based  on  Technical  Assistance  Downtime 
(Legacy  Estimate) 


Number  of  Technical  Assistance  Requests  by  the  Fleet 

Legacy  Estimate  Legacy  Estimate 

Cost  With  D  SHEL  Cost  Without  D  SHEL 


Figure  101.  Annual  Cost  of  Technical  Assistance  with  Legacy  Estimate 
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System  Cost  Based  on  Technical  Assistance  Downtime 
(M&S  Estimate) 


o 

E- 


o 

U 


Number  of  Technical  Assistance  Requests  by  the  Fleet 


•M&S  Estimate 
Cost  With  DSHEL 


•M&S  Estimate 
Cost  Without  DSHEL 


Figure  102.  Aimual  Cost  of  Technical  Assistance  with  M&S  Estimate 


Table  30.  Annual  Cost  of  Technical  Assistance 


#  Tech 

Legacy  Cost 

Legacy  Cost 

M&S  Cost 

M&S  Cost 

Assists 

w/  DSHEL 

w/out  DSHEL 

w/  DSHEL 

w/out  DSHEL 

1 

$364,051 

$15,390 

$367,938 

$18,938 

2 

$365,191 

$30,780 

$372,966 

$37,876 

3 

$366,331 

$46,170 

$377,993 

$56,815 

4 

$367,471 

$61,560 

$383,020 

$75,753 

5 

$368,611 

$76,950 

$388,048 

$94,691 

6 

$369,751 

$92,340 

$393,075 

$113,629 

7 

$370,891 

$107,730 

$398,103 

$132,567 

8 

$372,031 

$123,120 

$403,130 

$151,506 

9 

$373,171 

$138,510 

$408,157 

$170,444 

10 

$374,311 

$153,900 

$413,185 

$189,382 

11 

$375,451 

$169,290 

$418,212 

$208,320 

12 

$376,591 

$184,680 

$423,240 

$227,258 

13 

$377,731 

$200,070 

$428,267 

$246,197 
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#  Tech 

Legacy  Cost 

Legacy  Cost 

M«&S  Cost 

M&S  Cost 

Assists 

w/  DSHEL 

w/out  DSHEL 

w/  DSHEL 

w/out  DSHEL 

14 

$378,871 

$215,460 

$433,294 

$265,135 

15 

$380,011 

$230,850 

$438,322 

$284,073 

16 

$381,151 

$246,240 

$443,349 

$303,011 

17 

$382,291 

$261,630 

$448,377 

$321,949 

18 

$383,431 

$277,020 

$453,404 

$340,888 

19 

$384,571 

$292,410 

$458,431 

$359,826 

20 

$385,711 

$307,800 

$463,459 

$378,764 

21 

$386,851 

$323,190 

$468,486 

$397,702 

22 

$387,991 

$338,580 

$473,514 

$416,640 

23 

$389,131 

$353,970 

$478,541 

$435,579 

24 

$390,271 

$369,360 

$483,568 

$454,517 

25 

$391,411 

$384,750 

$488,596 

$473,455 

26 

$392,551 

$400,140 

$493,623 

$492,393 

27 

$393,691 

$415,530 

$498,651 

$511,331 

28 

$394,831 

$430,920 

$503,678 

$530,270 

29 

$395,971 

$446,310 

$508,705 

$549,208 

30 

$397,111 

$461,700 

$513,733 

$568,146 

Initially,  it  can  be  seen  that  the  cost  of  no  development  or  inclusion  of  a  DSHEL 
is  fai'  cheaper  when  the  Fleet  has  veiy  few  technical  assistance  requests  to  support  HEL. 
However,  as  the  uimiber  of  tech  assists  per  year  grows,  the  breakeven  point  becomes 
apparent  (higlilighted  in  Table  30).  More  specifically,  26  technical  assistance  requests  in 
a  year'  is  the  breakeven  point  in  which  DSHEL  begins  to  “pay  for  itself’  based  on  the 
legacy  average  cost  of  technical  assistance  study.  However,  given  HEL  is  an  inunatme 
weapon  system  compared  to  legacy  systems,  comparatively  the  tailored  M&S  results 
determined  the  breakeverr  poiirt  to  be  27  technical  assistance  reqirests.  While  the  plots 
intersect  at  a  pomt  in  between  26  and  27  technical  assistance  reqirests,  the  breakeven 
point  is  roimded  up  to  accoimt  for  the  fact  that  it  is  impossible  to  have  a  fiaction  of 
technical  assistance. 
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The  model  not  only  provided  additional  validation  to  studies  performed  by  an 
external  organization,  but  provided  validation  that  the  relevancy  and  accuracy  of  the 
estimate  is  on  par  with  the  assumptions  made  in  this  cost  analysis.  It  must  be  noted  that 
this  cost  estimate  was  based  on  a  limited  number  of  ships  with  HEL  actually  employed, 
leveraging  a  DSHEL  subsystem  to  enable  distance  support.  Eurther  expanding  on  the 
results  from  the  legacy  estimate,  given  the  number  of  ships  with  HEE  in  this  model  was 
assumed  to  be  30,  the  likelihood  of  27  technical  assistance  request  per  year  is  quite 
probable  given  the  severe  complexity  of  the  HEE  system  and  its  introduction  to  the  Elect 
as  a  never  before  seen  weapon  system  type.  Euture  work  to  refine  this  model  is  necessary 
once  a  PoR  configuration  of  HEE  has  been  identified  to  identify  a  fielding  plan  for 
number  of  shipboard  installations.  However,  even  in  the  current  legacy  cost  model,  if 
every  ship  with  HEE  in  this  analysis  at  least  submitted  one  help  ticket  request  for  their 
system  per  year,  the  comparison  for  supporting  30  technical  assistance  requests  with 
DSHEE  had  an  annual  estimate  of  $513,733  compared  to  supporting  requests  without 
DSHEE  at  an  estimate  of  $568,146.  That  result  is  an  annual  labor  and  travel  cost  savings 
of  $54,413  per  year,  or  more  importantly  $1.09M  over  the  20-year  life  cycle.  In  addition 
to  the  increased  issue  resolution  and  overall  Ao  to  perform  the  mission,  this  cost  benefit 
analysis  has  shown  the  significant  financial  savings  DSHEE  would  provide  to  USN.  As  a 
reminder,  this  cost  benefit  is  limited  to  the  labor  and  travel  associated  with  technical 
assistance.  Euture  work  involving  ePrognostics  and  Self  Repair  and  Healing  (the  latter 
two  pillars  of  DS)  is  expected  to  reveal  even  greater  cost  savings  in  the  failure  prevention 
of  expensive  HEE  subsystem  components. 

C.  RISK  ANALYSIS  APPROACH 

This  section  aimed  to  objectively  present  the  findings  of  research  theories, 
processes,  DOD  mandates,  stakeholder  requirements,  and  methodologies  applicable  to 
the  risk  management  of  the  DSHEE  subsystem. 

Risk  is  inherent  to  any  engineering  or  management  effort.  Overall,  it  is  the 
probability  that  given  a  series  of  one  or  more  events,  something  with  a  negative  outcome 
will  occur.  There  are  many  ways  to  categorize  types  of  risk,  but  for  the  purposes  of  this 
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capstone  report  focusing  on  SE  of  a  defense  program,  those  eategories  were  stated  in 
terms  of  eost,  sehedule,  and  teehnieal  performanee.  Cost  risk  is  the  probability  whieh  the 
alloeated  budget  of  the  project  will  be  exeeeded  in  some  manner.  Sehedule  risk  is  the 
probability  whieh  the  projeet  will  fail  to  meet  key  dates  or  milestones  by  a  specified 
duration.  Technical  performance  risk  is  the  probability  whieh  the  key  performance 
parameters  of  the  system  are  negatively  affected.  Regardless  of  the  risk  type,  there  needs 
to  exist  a  formalized  proeess  to  identify,  assess,  and  prioritize  eaeh  risk;  this  is  known  as 
risk  management. 

The  practiee  of  risk  management  is  broken  down  into  an  iterative  proeess  whieh 
extends  the  life  of  the  program  from  eradle  to  grave.  Blanehard  and  Fabryeky  deseribe 
this  proeess  as  follows  (Blanehard  and  Fabryeky  2011,  692): 

1 .  Risk  planning — ineludes  the  development  of  a  risk  management  plan  or  a 
given  program. 

2.  Risk  identifieation — ineludes  the  sereening  of  all  eost,  sehedule,  and 
teehnieal  performance  requirements  and  to  identify  whieh  of  those  are 
likely  not  to  be  met. 

3.  Risk  assessment — pertains  to  determining  the  probability  of  failure  to 
meet  a  speeified  requirement  and  the  possible  consequenees  of  not 
meeting  the  requirement. 

4.  Risk  analysis — is  aeeomplished  to  determine  the  way  in  whieh  the  risk  ean 
be  eliminated  or  minimized  (if  the  risk  eannot  be  eliminated  altogether). 

5.  Risk  handling — includes  the  aetivities  assoeiated  with  the  ineorporation  of 
ehanges  to  business  proeess  or  system  modifieation  whieh  are 
reeommended  as  a  solution  to  the  identified  problem. 

While  the  aforementioned  steps  are  speeifie  in  high  level  guidanee,  different 
methodologies  exist  for  tailoring  the  proeess  to  best  fit  the  projeet.  The  remaining 
seetions  explored  a  few  of  these  methodologies,  their  eapabilities  and  limitations,  for  the 
identifieation  of  stakeholder  requirements  and  management  of  risk  to  DSHEF. 

1,  DOD  Risk  Management  Guide 

The  Department  of  Defense  Risk  Management  Guide  (Department  of  Defense 


2006)  exists  to  assist  DOD  and  contraetor  Program  Managers  (PMs),  Program  Offices, 
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and  integrated  product  teams  (IPTs)  to  effectively  manage  risks  during  the  life  cycle  of  a 
program.  It  provides  a  standard  framework  and  methodology  of  assessment  and 
presentation  which  is  common  to  all  branches  of  DOD.  By  using  this  framework  to 
manage  risk,  a  format  which  is  common  to  program  managers  and  officers  of  the  DOD, 
the  methodology  of  status  reporting  can  be  normalized  for  the  program.  The  RMG 
dictates  that  every  program  shall  create  a  risk  management  plan  specifically  tailoring  the 
individuals  responsible  for  the  integrated  product  teams,  those  accountable,  and 
responsible  for  the  process  of  risk  management. 


Figure  103.  DOD  Risk  Management  Process  (after  Department  of  Defense  2006) 

While  the  plan  is  tailored  via  the  SE  process  to  best  fit  the  need  of  the  program, 
the  general  process  described  in  the  Figure  103.  When  risks  are  identified,  they  shall  be 
expeditiously  entered  in  to  the  risk  management  process  where  an  IPX  will  assess  their 
impact.  Assessment  is  performed  during  the  analysis  phases  where  a  number  of  criteria 
based  on  cost,  schedule,  and  technical  performance  are  used  to  determine  the  Likelihood 
and  Consequence  of  occurrence.  Table  31  displays  the  standard  nomenclature  for 
translating  probability  of  occurrence  to  the  wording  of  a  given  likelihood.  This  is  to  be 
used  when  another  standard  doesn’t  already  exist  to  refine  and  supersede  the  assessment 
criteria  presented  in  the  RMG.  For  the  purposes  of  DSHEL,  the  team  also  included 
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NAVSEAINST  9410.2A  for  Warfare  System  Certification  or  MILSTD-882G  for  Safety 
assessments  to  better  refine  the  risk  model. 


Table  3 1 .  Risk  Analysis  for  Levels  of  Likelihood  (from  Depaifment  of  Defense  2006) 


Level 

Likelihood 

Probability  of 
Occurrence 

1 

Not  Likely 

-10% 

2 

Low  Likelihood 

-30% 

3 

Likely 

-50% 

4 

Highly  Likely 

-70% 

5 

Near  Certainty 

-90% 

Consequence  assessment,  however,  is  more  involved  as  it  is  assessing  the  impact 
in  relationsliip  to  cost,  schedule,  and  perfoimance.  Cost  and  schedule  are  based  upon 
known  quantities  of  the  project  and  how  a  risk  could  impact  a  given  percentage  of  the 
budgeted  resource.  Those  details  are  outlined  in  the  risk  management  plan  when  such 
project  details  are  known;  however,  this  capstone  will  later  identify  and  refine  risks 
following  methodology  assessments  based  on  the  cost  analysis  and  projection  scale. 
Technical  perfoimance  impact  requhes  a  breadth  of  teclmical  knowledge  of  the  system 
risk  being  analyzed  to  properly  categorize  impact.  However,  just  as  with  the  likelihood 
criteria,  the  RMG  provides  a  boilerplate  guideline  which  is  allowed  to  be  superseded 
when  other  DOD  instnictions  exist,  which  refine  or  tailor  the  process.  For  the  pmposes  of 
DSHEL,  the  team  also  included  the  DOD  Infomiation  Assurance  Risk  Management 
Framework  for  Cybersecmity.  An  example  consequence  table  from  RMG  is  illustrated  in 
Table  32. 
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Table  32.  DOD  Levels  and  Type  of  Consequence  Criteria  (Department  of  Defense  2006) 


Level 

Technical  Performance 

Schedule 

Cost 

1 

Minimal  or  no  consequences  to 
technical  perfoimance 

Muiimal  or  no 
impact 

Minimal  or  no 
impact 

2 

Minor  reduction  in  teclmical 
perfoimance  or  supportability, 
can  be  tolerated  with  little  or  no 
impact  on  progiam 

Able  to  meet  key 
dates 

Slip  <  *  day(s) 

Budget  increase  or 
imit  production  cost 
increases 

<  **  (1%  of  Budget) 

3 

Moderate  reduction  in  technical 
perfoimance  or  supportability 
with  limited  impact  on  progiam 
objectives 

Minor  schedule  slip. 
Able  to  meet  key 
milestones  with  no 
schedule  float 

Slip  <  *  day(s) 

Sub-system 
slip  >  *  day(s)  plus 
available  float 

Budget  increase  or 
unit  production  cost 
increases 

<  **  (5%  of  Budget) 

4 

Significant  degiadation  in 
technical  perfoimance  or  major 
shortfall  in  supportability;  may 
jeopardize  program  success 

Program  critical 
path  affected 

Slip  <  *  days 

Budget  increase  or 
imit  production  cost 
increase 

<  **  (10%  of 
Budget) 

5 

Severe  degiadation  in  technical 
perfoimance;  cannot  meet  KPP  or 
key  technical/supportability 
threshold;  supportability;  will 
jeopardize  program  success 

Cannot  meet  key 
progiam  milestones 

Slip  >  *  days 

Exceeds  APB 
threshold 

>**(10%  of 
Budget) 

Following  analysis,  the  risk  mitigation  path  is  equally  as  involved  and  important. 
This  is  where  the  IPT  decides  the  best  path  foiwaid  to  manage  the  risk  before  it  occms 
(or  mitigate  the  issue  if  it  has  aheady  manifested  itself).  This  kicks  off  an  iterative 
process  of  plaiming,  executmg,  and  status  repoifing  imtil  the  risk  can  be  minimized  or 
eliminated  altogether.  The  status  is  tracked  and  continuously  reported  out  to  the  Project 
Manager  by  the  systems  engineer.  A  feedback  loop  exists  in  the  process  for  refinement. 

244 


An  example  of  a  risk  status  reporting  matrix  ean  be  seen  in  Figure  104  showing  a 
“stoplight”  assessment  where  the  likelihood  and  consequence  results  fall  into  a  risk  area 
of  high  (red),  medium  (yellow),  or  low  (green). 


Consequence 

Figure  104.  Example  Risk  Matrix 


Overall,  the  DOD  RMG  provides  the  necessary  framework  to  facilitate  effective 
communication  of  DSHEL  risk  in  a  manner  which  is  familiar  to  programmatic 
stakeholders.  It  is  the  recommended  methodology  by  DOD  to  formalize  risk  management 
into  the  process  familiar  to  the  organization  such  that  the  IPTs  can  focus  their  energy 
more  on  managing  risk  rather  than  explaining  a  unique  unfamiliarity. 

2,  DOD  Risk  Management  Framework 

The  DOD  Information  Assurance  Risk  Management  Eramework  (RME)  ties 
together  the  aforementioned  topics  of  cybersecurity  and  risk  management.  This  process  is 
meant  to  better  refine  the  technical  impact  of  risk  when  it  relates  to  information 
assurance.  The  overall  instruction  derives  from  the  National  Institute  of  Standards  and 
Technology  (NIST)  800-53  and  better  aligns  the  DOD  with  the  rest  of  the  Eederal 
government  in  how  it  shall  identify,  assess,  manage,  and  report  cybersecurity  risk.  While 
the  specific  implementation  of  the  Naval  Instruction  tailoring  for  DON  has  not  been 

released  at  the  time  of  this  writing,  it  shall  align  with  the  RME.  Therefore,  this  capstone 
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report  focused  on  the  instruction  set  forth  by  DOD  with  the  caveat  that  when  creating  a 
DSHEL  further  refinement  and  tailoring  for  the  USN  RMF  process.  DOD  is  not  requiring 
immediate  transition  to  the  RMF  upon  release  in  order  to  allow  time  for  critical 
supporting  guidance,  automated  tool  updates,  and  training  from  DOD  and  the 
components  to  be  developed  and  released.  By  FY15,  the  DON  chief  information  officer 
(DON  CIO)  will  release  policy  addressing  component  specific  guidance  regarding 
transition  of  all  DON  information  systems  and  platform  IT  systems  to  the  RMF  in 
accordance  with  the  DOD  timelines  (Department  of  Navy  2014). 

Where  the  RMF  specifically  aligns  with  the  DOD  RMG,  is  in  the  assessment 
portion  of  the  risk  management  process.  During  development  of  a  system,  for  purposes  of 
accreditation,  the  information  technology  system  shall  be  identified  as  an  information 
system,  platform  information  technology,  IT  services,  or  IT  products  as  indicated  in 
Figure  105. 


Figure  105.  DOD  Information  Technology  Categorization  for  RMF  (from  Department 

of  Defense  2014) 


Based  on  a  system’s  required  functionality  and  capabilities,  once  it  is  categorized, 
the  RMF  provides  a  set  of  cybersecurity  requirements  alongside  STIGs  as  well  as 
whether  or  not  the  system  requires  an  authorization  in  addition  to  risk  assessment.  Not  all 
requirements  can  be  100%  implemented  as  it  would  degrade  performance  of  the  system 
from  executing  some  functions.  RMF  dictates  that  as  many  of  the  requirements  as 
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feasible  shall  be  implemented  until  required  functionality  or  technical  performance  is 
impacted  and  design  cannot  be  mitigated  to  accommodate  the  security  control.  At  this 
point  whatever  security  vulnerabilities  are  left  open  must  be  identified  as  known  risks  to 
the  system  and  can  be  assessed  for  consequence  in  accordance  with  the  Committee  of 
National  Security  Systems  Instruction  CNSSI-1253.  Cybersecurity  has  created  its  own 
sub  framework  for  risk  management,  it  is  the  amount  a  risk  the  program  office,  customer, 
and  certification  officials  are  willing  to  accept  based  on  required  functionality  therewith 
the  mitigation  of  security  vulnerabilities  which  remain. 

The  RMF  process  shows  the  certification  and  authorization  procedures  necessary 
for  lA.  The  assessment  step,  the  fourth  box,  can  directly  correlate  and  report  out  to  the 
overall  risk  management  process  for  conveying  risk  to  the  project  sponsor.  In  tandem,  it 
provides  a  dual  feedback  loop  where  the  sponsor  can  be  informed  of  overall 
programmatic  risk.  While  specific  to  cybersecurity,  the  risk  can  be  conveyed  to  the 
designation  officials  determining  if  the  system  is  secure  enough  to  obtain  certification. 
The  RMF  consists  of  the  steps  depicted  in  Figure  106.  This  process  parallels  the  system 
life  cycle  with  the  RMF  activities  being  initiated  (a  program  or  system  inception,  i.e., 
documented  during  capabilities  identification  or  at  the  implementation  of  a  major  system 
modification).  Per  the  updated  instruction,  “failure  to  initiate  the  RMF  at  system  or 
program  inception  is  not  a  justification  for  ignoring  or  not  complying  with  the  RMF” 
(Department  of  Defense  2014,  27).  While  the  full  details  are  contained  in  the  instruction 
itself,  this  necessity  is  not  to  be  taken  lightly.  The  proper  management  of  cybersecurity  in 
accordance  with  RMF  is  the  responsibility  of  all  programs  in  DOD.  Passive  stakeholder 
requirements  will  need  to  be  captured  in  any  project’s  risk  management  plan  such  that  in 
addition  to  cost,  schedule,  and  technical  performance,  cybersecurity  becomes  a  technical 
subset  of  the  performance  categorization. 
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Figure  106.  RMF  for  Information  Systems  and  PIT  Systems  (from  Department  of  Defense  2014) 
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In  accordance  with  the  NAVSEA  Warfare  System  Certifieation  eriteria  defined  in 
NAVSEAINST  9410. 2A,  the  following  risk  assessment  priorities  have  been  defined  with 
respeet  to  lA  and  the  impaets  to  eertifieation  and  systems  performanee.  It  must  be  noted, 
that  unlike  the  DOD  RMG  whieh  assess  risk  with  Consequenee  1  being  the  best  ease  and 
Consequenee  5  being  the  worst,  the  rating  faetor  is  switehed  where  there  worst  ease  is 
Consequenee  1  and  best  ease  is  Consequenee  5.  The  worst  ease,  Consequenee  1,  defines 
risk  as  a  “Problem  that  negatively  impacts  information  systems  security  posture  and 
results  in  the  loss  of  authority  to  operate  (ATO)”  (Naval  Sea  Systems  Command  2012). 
Consequenee  2  defines  risk  as  a  “Problem  (that)  degrades  /  adversely  affects  information 
security  posture  and  results  in  a  reduced  set  of  eapabilities.”  Consequenee  3  defines  risk 
as  a  “Problem  that  degrades/adversely  affeets  information  systems  seeurity  posture  but 
allows  an  interim  authority  to  operate  (lATO).”  Consequenees  4  and  5  do  not  provide  any 
definitions  to  assess  information  assuranee  related  risk,  as  beyond  level  three  they  do  not 
impaet  eertifioation.  At  this  point,  the  eonsequenee  ean  be  treated  generieally  as  any  other 
teehnieal  impact,  where  a  Consequenee  4  “Problem  results  in  user/operator 
inconvenienee  or  annoyance  and  does  not  affect  required  operational  or  mission  essential 
eapability  (or)  results  in  a  minor  system  degradation  that  does  not  prevent  ownership 
aeeomplishment  of  an  operational  or  mission  eritieal/essential  function  and/or  ship 
operations.”  Consequenee  5  defines  risk  as  “An  error  that  does  not  affeet  the  system  or 
operator  from  aeeomplishing  a  funetion  in  aoeordanee  with  system  requirements;  a 
speeifieation  error  that  does  not  affeet  the  software;  an  error  that  does  not  affeet  warfare 
systems  operations.” 

3,  Tailored  Risk  Management  Methodology 

By  leveraging  the  aforementioned  guidanee  on  eyberseeurity,  warfare  systems 
eertifieation,  and  resulting  eost  analysis,  the  DOD  RMG  table  for  assessing  risk 
eonsequenee  was  tailored  for  DSHEE  teehnieal  performanee,  sehedule,  and  eost.  With 
regards  to  eyberseeurity,  the  risk  assessment  relating  to  warfare  systems  certifieation 
shall  be  ineluded  into  the  appropriate  teehnieal  performance  areas;  their  eonsequenees 
obviously  being  switehed  to  align  properly  given  the  assessment  seale  for  RMG  goes 
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from  1  to  5,  and  warfare  systems  certification  goes  from  5  to  1,  describing  best  to  worst 
case.  Schedule  was  leveraged  from  the  COSYSMO  and  COCOMO  n  estimates,  with 
initial  SE  efforts  supporting  Software  in  parallel  with  an  estimate  of  16.8  person  months 
(67  person  weeks).  Given  the  development  of  a  detailed  project  schedule  is  beyond  the 
scope  of  this  study,  the  higher  level  COCOMO  schedule  was  used  to  identify  key  periods 
and  milestones:  2.1  months  for  the  inception  phase,  6.3  months  for  the  elaboration  phase, 
10.5  months  for  constniction,  and  2.1  months  for  transition  to  operation.  The  individual 
phases  will  be  used  to  assess  diuation  impact  to  meet  key  dates,  with  the  assiunption  that 
25-30%  float  exists  to  accommodate  a  schedule  slip  within  an  individual  phase.  Given 
the  project’s  critical  elaboration  phase  has  only  6.3  months  (25.2  weeks)  for  execirtion, 
these  estimates  approximately  7.5  weeks  of  slippage  imtil  the  critical  path  is  affected.  Tire 
resulting  schedule  impacts  were  then  assessed  proportionately.  Finally,  with  respect  to 
Cost,  the  total  budget  for  DSHEL  acqirisition  was  estimated  to  be  $2,316,315,  whereas 
1%  impact  would  be  $23,163,  5%  would  be  $115,816,  and  10%  would  be  $231,632 
respectively.  Table  33shows  the  resirltiug  risk  mauagemerrt  assessment  criteria,  tailored 
for  the  specifics  of  DSHEL. 


Table  33.  DSHEL  Tailored  Risk  Management  Assessmerrt  Criteria  (after  Department  of 

Defense  2006) 


Level 

Technical  Performance 

Schedule 

Cost 

1 

Minimal  or  no  corrseqirences  to 
technical  performance 

Minimal  or  no 
impact 

Minimal  or  no 
impact 

2 

Minor  redirctiorr  in  teclmical 
performance  or  supportability,  can 
be  tolerated  with  little  or  no  impact 
on  program 

Able  to  meet  key 
dates 

Slip  <  2  Weeks 

Birdget  increase 
or  imit  production 
cost  increases 

<  $23,163 
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Level 

Technical  Performance 

Schedule 

Cost 

3 

Moderate  reduction  in  technical 
performance  or  supportability  with 
limited  impact  on  progr  am 
objectives 

Problem  that  degrades/adversely 
affects  urformation  systems  secmity 
postiue  birt  allows  an  hrterirn 
Airthority  to  Operate  (lATO) 

Minor  schedule 
slip.  Able  to  meet 
key  milestones  with 
no  schedule  float 

Slip  <  3.25  Weeks 

Sub-system  slip  > 
3.25  Weeks  plus 
available  float 

Budget  increase 
or  imit  production 
cost  increases 

<$115,816 

4 

Significant  degradation  in  technical 
performance  or  major  shortfall  in 
supportability;  may  jeopardize 
program  sirccess 

Problem  degrades  /  adversely  affects 
information  secirrity  posture  and 
results  m  a  redrrced  set  of 
capabilities 

Program  critical 
path  affected 

Slip  <  7.5  Weeks 

Budget  increase 
or  imit  production 
cost  increase 

<$231,632 

5 

Severe  degradation  in  technical 
performance;  Carmot  meet  KPP  or 
key  teclmical/sirpportability 
threshold;  supportability;  will 
jeopardize  program  sirccess 

Problem  that  negatively  impacts 
information  systems  security  postirre 
and  results  in  the  loss  of  ATO 

Carmot  meet  key 
program  milestones 

Slip  >  7.5  Weeks 

Exceeds  APB 
threshold 

>$231,632 

D.  RISK  ANALYSIS  AND  RESLTLTS 

The  following  section  applies  the  tailored  risk  management  assessment  criteria  to 
risks  identified  dining  the  research  of  DSHEL.  This  included  assessments  of  likeldiood 
and  consequence,  alongside  recommended  mitigations. 

1.  Risk  1 — Maturity  of  RMA  Data 

Accmate  data  of  a  system  regarding  its  components  reliability,  maintainability, 
and  availability  presents  a  complex  issue  when  planning  for  DS.  Real  world  data  is 
needed  for  refined  results  that  represent  an  operational  maritime  environment;  however, 
this  is  not  readily  available  for  a  first  of  its  kind  system  such  as  HEL.  Not  knowing  the 
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true  reliability  of  these  laser  components  leads  to  the  possibility  of  over  monitoring  HEL 
components  or  not  monitoring  the  correct  ones.  Fortunately,  many  of  the  HEL 
components  require  system  monitoring  for  normal  operations  to  compute  battle  damage 
assessment  as  well  as  determining  ready  to  fire  status.  The  critical  components  will  most 
likely  be  monitored  and  their  status  made  available  for  DSHEL  to  pull.  However,  the  risk 
exists  that  without  operationally  RMA  data,  it  is  unknown  exactly  which  HEL 
components  merit  monitoring  in  a  maritime  environment  and  a  critical  component  may 
not  be  monitored. 

•  Risk  Nomenclature:  (Rl)  Maturity  of  RMA  Data 

•  Consequence:  Moderate  reduction  in  technical  performance  or  supportability 
with  limited  impact  on  program  objectives 

•  Likelihood:  Likely 50% 

•  Recommended  Mitigation:  Directed  Energy  SME  analysis  is  necessary  in 
tandem  with  logistical  efforts  to  create  Failure  Mode,  Effects,  and  Criticality 
Analysis  (FMECA)  to  predict  and  identify  critical  parts  for  sensorization. 
FMECA  is  a  required  logistics  artifact  necessary  as  entrance  criteria  to  present 
at  Milestone  B,  finalized  by  Milestone  C.  By  leveraging  this  data,  an  educated 
prediction  can  be  made  with  respect  to  monitor  the  correct  parts  and  refined 
over  time  as  the  system  operates  and  real  world  data  is  collected. 

The  Rl  risk  assessment  is  determined  to  be  (Consequence  =  3,  Likelihood  =  3). 

2.  Risk  2 —  Common  USN  Data  Format 

The  USN  has  moved  away  from  MILSTD  type  requirements  for  transmitting  and 
reporting  system  status,  leaning  more  towards  the  recommendation  that  a  program  will 
use  open  standards.  While  this  gives  flexibility  to  the  contractors,  it  results  in  a  wide 
diversity  in  data  reporting  formats  across  all  USN  systems,  resulting  in  not  having  a 
single  program  of  record  software  application  which  can  read  and  reuse  this  data.  To 
minimize  the  cost  of  DS  by  reuse  of  existing  COTS/FOSS  software  applications,  it  is 
imperative  that  a  standardized  open  format  is  chosen  for  use,  and  that  HEL  reports  its 
data  in  this  format  to  DSHEL.  The  data  format  requirement  from  DSHEL  recommends  a 
common  industry  standard  reporting  format  on  HEL  to  help  mitigate  this,  such  as  simple 
network  management  protocol  version  3  (SNMPv3).  Without  doing  this,  the  risk  is  that 

DSHEL  will  not  be  able  to  integrate,  read,  and  report  status  ashore  to  meet  its  mission 
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requirements.  It  is  not  likely  that  this  would  happen  as  HEL  is  early  in  the  development 
cycle  and  this  requirement  is  being  proposed  early  on  for  the  inclusion  of  DSHEL. 

•  Risk  Nomenclature:  (R2)  Common  USN  Data  Eormat  not  defined 

•  Consequence:  Cannot  meet  key  technical/supportability  threshold  and  will 
jeopardize  program  success 

•  Eikelihood:  Near  Certainty  90% 

•  Recommended  Mitigation:  Require  use  of  industry  standard  IEEE  defined 
data  formats  for  HEE  sensorization,  health  monitoring,  and  test  results 
(SNMPv3)  such  that  EOSS  can  be  leveraged  for  software  functionality. 

The  R2  risk  assessment  is  determined  to  be  (Consequence  =  5,  Eikelihood  =  5). 

3.  Risk  3 — Classification  of  HEL  Data 

The  classification  of  weapon  system  data,  specifically  HEE,  drives  the 
cybersecurity  requirements  and  controls  necessary  to  obtain  an  ATO.  HEE  is  unique  in  its 
application,  as  it  is  a  ship  self-defense  weapon  and  an  extremely  accurate  long  range 
optical  sight  which  could  be  used  as  an  ancillary  shipboard  sensor.  The  former  use,  as 
ship  self-defense,  is  typically  unclassified.  However,  shipboard  sensors  and  optical  sights 
typically  have  a  classified  data  set  as  they  provide  unique  information  used  to  create 
tracks  managed  by  the  ship’s  combat  system.  The  risk  is  that  an  assumption  is  made  to 
use  DSHEE  with  an  unclassified  data  set  when  in  the  future  the  classification  of  HEE 
could  be  escalated  given  an  ancillary  use,  thereby  invalidating  the  existing  DSHEE 
cybersecurity  accreditation. 

•  Risk  Nomenclature:  (R3)  Classification  of  HEE  Data 

•  Consequence:  Problem  that  negatively  impacts  information  systems  security 
posture  and  results  in  the  loss  or  inability  to  obtain  ATO 

•  Eikelihood:  Not  Eikely 10% 

•  Recommended  Mitigation:  Assume  worst  case  that  HEE  data  is  classified  and 
structure  security  posture  to  satisfy  these  controls  with  the  RME 
confidentiality  rating  of  high 

The  R3  risk  assessment  is  determined  to  be  (Consequence  =  5,  Eikelihood  =  1). 
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4,  Risk  4 — Hardware  Processing  Drives  Software  Licensing  Costs 

The  use  of  COTS/FOSS  software  comes  with  OEM  license  agreements  for 
operational  usage  and  support  in  the  form  of  patches  and  updates.  Regardless  of  the 
operational  usage  or  performance  requirements,  licensing  is  sometimes  based  on  the 
number  of  processing  cores  on  the  computer’s  central  processing  unit  (CPU).  Given  that 
the  cost  of  CPU  performance  is  relatively  cheap,  hardware  engineers  have  the  risk  of 
“gold  plating”  their  choice  of  computing  servers  and  using  processors  which  are  above 
and  beyond  what  is  necessary.  The  software  operating  platform  was  chosen  to  run 
virtualized  on  top  of  VMWare  ESXi  to  minimize  risk  of  future  hardware  technology 
refresh.  Virtualization  adds  an  abstraction  layer  between  the  operating  system  and 
computing  hardware,  thereby  making  the  hardware  appear  static  to  the  operating  system 
no  matter  what  the  choice  of  hardware  is.  This  incurs  an  upfront  cost  of  software 
licensing  to  minimize  the  risk  of  integration  efforts  further  on  in  the  life  cycle  when 
hardware  driver  issues  or  software  library  compatibility  typically  has  issues  with 
hardware  upgrades.  The  overall  risk  is  that  given  this  choice  of  architecture,  choosing  a 
server  which  has  hardware  performance  above  what  is  required  would  drive  software 
licensing  costs. 
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•  Risk  Nomenclature:  (R4)  Hardware  Processing  Drives  Software  Licensing 
Costs 

•  Consequence:  Exceeds  APB  threshold  >  $23 1 ,632 

•  Likelihood:  Low  Likelihood 30% 

•  Recommended  Mitigation:  SE  must  enable  and  manage  communication 
between  hardware  and  software  engineering  teams  that  “gold  plating”  of  a 
computer  server  processor  impacts  software  licensing  costs,  set  objective  and 
threshold  requirements  for  processor  cores. 

The  R4  risk  assessment  is  determined  to  be  (Consequence  =  5,  Likelihood  =  2). 

5,  Risk  5 — Training 

The  shipboard  process  of  enabling  distance  support  for  active  methods,  such  as 
remote  repair  or  remote  technical  assistance,  mandates  a  “man  in  the  loop”  philosophy  to 
ensure  the  oversight,  control,  and  operational  security  necessary  to  protect  the  system. 
Given  active  DS  methodologies  are  not  common  or  organic  to  naval  weapon  systems,  it 
is  imperative  that  detail  standard  operating  procedures,  technical  manuals,  and  training 
are  present  to  ensure  process  is  adhered  to  in  the  interest  of  cybersecurity  and  mission 
success.  The  risk  of  not  following  process  would  delay  the  responsiveness  of  DS  and 
increase  system  downtime. 

•  Risk  Nomenclature:  (R5)  Training 

•  Consequence:  Moderate  reduction  in  supportability  with  limited  impact  on 
program  objectives. 

•  Likelihood:  Low  Likelihood  ~  30% 

•  Recommended  Mitigation:  Detailed  documentation  and  hands  on  sailor 
training  at  ISEA  Laboratory  to  ensure  the  user  is  familiar  with  DSHEL  usage 
and  DS  process  adherence. 

The  R5  risk  assessment  is  determined  to  be  (Consequence  =  3,  Likelihood  =  2). 

6,  Risk  6 — Integration 

As  the  HEL  is  being  developed,  components  and  their  internal  level  of  integration 
are  in  flux.  DSHEL  depends  on  known  interfaces  and  message  types  to  enable  mission 
success.  As  the  HEL  progresses  to  a  mature  program  of  record,  the  risk  of  change 
impacts  integration  efforts,  causing  setbacks  to  reconfigure  DSHEL  to  monitor  the 
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appropriate  components.  While  there  is  an  expected  common  message  type,  the  HEL 
architecture  and  its  interfaces  must  be  relatively  static  to  complete  successful  integration 
efforts. 

•  Risk  Nomenclature:  (R6)  Integration 

•  Consequence:  Minor  schedule  slip,  able  to  meet  key  milestones,  slip  <  3.25 
Weeks 

•  Likelihood:  Highly  Likely  ~  70% 

•  Recommended  Mitigation:  HEL  engineering  changes  during  development 
shall  identify  impacted  interfaces,  physical  and  logical.  These  interfaces  shall 
be  captured  in  a  detailed  interface  control  document  and  specification.  A 
change  to  any  HEL  interface  will  trigger  review  by  the  DSHEL  team  for 
integration  impact. 

The  R6  risk  assessment  is  determined  to  be  (Consequence  =  3,  Likelihood  =  4). 

E.  SUMMARY 

The  following  risk  matrix,  shown  in  Ligure  107,  is  an  aggregate  rollup  of  all  risks 
identified  with  the  SE  efforts  associated  with  DSHEL.  While  a  majority  of  the  risk  is 
medium  (yellow),  the  mitigation  paths  presented  can  effectively  prevent  or  mitigate  this 
risk  from  occurring  to  achieve  successful  realization  of  DSHEL. 


Ligure  107.  DSHEL  Risk  Matrix 
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Risk  Matrix  Key 
R1  =  Maturity  of  RMA  Data 
R2  =  Common  USN  Data  Format 
R3  =  Classification  of  HEL  Data 

R4  =  Hardware  Processing  Drives  Software  Licensing  Costs 
R5  =  Training 
R6  =  Integration 
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VII.  CAPSTONE  SUMMARY 


A.  TECHNICAL  OUTCOMES 

The  first  section  of  Technical  Outcomes  covers  the  development  of  the  distance 
support  decision  process,  which  gave  the  support  provider  the  ability  to  determine  how 
much  distance  support  is  required  and  to  what  level  the  system  might  be  sensorized.  The 
second  section  discusses  the  modeling  and  simulation  findings  derived  from  an  existing 
distance  support  process.  The  last  section  details  the  findings  related  to  the  cost  analysis 
that  was  performed  for  the  DSHEL  system. 

1.  Distance  Support  Decision  Process 

In  determining  how  much  DS  is  required  and  to  what  level  a  system  must  be 
sensorized,  an  analysis  of  the  POI  as  well  as  the  PSP  culture  and  strategy  must  be 
conducted.  The  PSP  culture  and  strategy  must  first  be  understood  in  order  to  know  what 
type  of  DS  is  needed.  This  raised  the  question  of  whether  DS  was  a  product  or  a  service. 
This  is  dependent  on  PSP  culture  and  how  execution  of  DS  is  delivered.  However,  the 
PSP  strategy  must  also  be  taken  into  account,  as  an  organization  will  evolve  over  time. 
Providing  quality  DS  is  the  progressive  evolution  of  a  PSP  creating  an  environment  in 
which  they  are  no  longer  involved. 

DS  for  a  POI  begins  with  the  understanding  of  the  POI’s  environment  and 
interface  interactions.  A  holistic  systems  view  must  be  taken.  DS  is  not  isolated  to  one 
DS  element:  PSP,  ESI,  or  POI.  DS  is  the  effective  collaboration  of  these  elements 
through  SEAs  and  OEAs  within  the  enterprise  ecosystem.  Only  when  these  interactions 
and  business  process  flows  are  understood,  can  an  analysis  of  the  POI  begin.  The  POI 
must  be  classified  as  an  “independent  platform”  or  as  a  “guest  platform  contained  within 
a  host  platform.”  This  classification  offers  insight  into  the  next  decision,  DSX 
configuration.  The  multiple  DSX  configurations  (integrated  -  single-point  all  inclusive, 
encompassing  -  single-point  semi  inclusive,  distributed  -  multipoint  all  inclusive, 
distributed  -  multipoint  semi  inclusive)  offer  the  PSP  flexibility  in  terms  of  POI  life- 
cycle  phase,  cost,  capability,  scalability,  and  complexity.  These  are  used  to  meet  the 
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minimum  data  picture  completeness  threshold  to  provide  meaningful  I2DF  in  delivering 
quality  DS. 

The  level  of  sensorization  and  sensor  collection  network  topology  chosen  by  the 
PSP  for  the  POI  is  highly  dependent  on  the  minimum  data  picture  completeness  threshold 
set  by  the  PSP.  Once  the  above  steps  are  met,  the  PSP  executes  a  POI  system 
decomposition  to  an  acceptable  level  where  the  I2DF  set  is  adequately  detailed.  These 
components  are  then  analyzed  for  inherent  sensor  capabilities  and  are  either  sensorized  or 
added  to  the  sensor  collection  network  with  characteristics  as  defined  by  the  POI  SMEs. 

2.  Modeling  Distance  Support 

Through  the  employment  of  modeling  and  simulation  tools,  the  effects  of  three 
types  (no  DS,  status  quo  DS,  integrated  DS)  of  distance  support  were  analyzed.  The  time- 
based  analysis  showed  significant  reduction  in  mean  down  time  (MDT)  for  integrated 
distance  support  while  it  significantly  increased  for  no  distance  support  in  relation  to  the 
status  quo.  Reduction  in  MDT,  ceteris  paribus,  causes  improvement  in  Ao.  The  baseline 
status  quo  distance  support  model  indicated  a  MDT  of  149.0  hours,  a  standard  deviation 
of  91.5  hours,  with  a  resulting  Ao  of  0.770.  Integrated  distance  support  showed 
significant  improvement  with  a  MDT  of  83.8  hours,  a  standard  deviation  of  44.9  hours, 
with  a  resulting  Ao  of  0.856.  Conversely,  elimination  of  distance  support  was  detrimental 
to  reliability  with  a  mean  downtime  of  335.1  hours,  a  standard  deviation  of  210.5  hours, 
and  Ao  of  0.559.  The  M&S  portion  of  this  study  details  the  simulated  downtime 
distributions  that  are  suggested  for  use  in  future  distance  support  decision  making  as 
related  to  HEL  and  other  USN  systems. 

3.  Cost  Analysis 

By  applying  the  high-level  requirements  set,  which  drove  the  DS  framework, 

architecture  interfaces,  and  M&S  results  to  standard  systems  engineering  cost  estimation 

methodologies  based  on  COSYSMO  and  COCOMO  II,  cost  savings  were  shown  over  the 

life  cycle  of  HEE.  This  analysis,  based  on  a  20  year  life  cycle  of  HEE  installed  on  30 

shipboard  platforms,  resulted  in  an  estimate  of  $7,258,215  for  the  addition  of  a  DSHEE 

component,  an  average  of  $362,91 1  a  year.  The  cost  of  a  system,  throughout  its  life  cycle, 
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is  thereby  shown  to  grow  based  on  how  much  support  it  requires  and  cost  per  technical 
assistance.  By  incorporating  the  estimated  DSHEL  life-cycle  cost  with  the  M&S  results 
for  estimated  downtime,  a  cost  per  technical  assistance  was  determined  to  show  the 
eventual  breakeven  point  in  which  a  distance  support  subsystem,  such  as  DSHEL,  would 
pay  for  itself  Given  30  HEL  platforms,  the  integrated  results  from  M&S  have  shown  that 
DSHEL  would  begin  to  show  a  return  on  investment  once  27  technical  assistance 
requests  have  occurred  as  shown  in  Eigure  108.  This  accounts  for  the  fact  that  a  fractional 
technical  assistance  request  is  impossible  and  that  it  must  round  up  to  the  next  technical 
assistance  request  to  cross  the  break-even  point. 


System  Cost  Based  on  Technical  Assistance  Downtime 
(M&S  Estimate) 


u 

H 


o 

U 


Number  of  Technical  Assistance  Requests  by  the  Fleet 


•M&S  Estimate 
Cost  With  DSHEL 


-M&S  Estimate 
Cost  Without  DSHEL 


Eigure  108.  Annual  Cost  of  Technical  Assistance 


Overall,  given  the  complexity  of  a  system  such  as  HEL  being  first  of  its  kind  in 
the  Elect,  it  is  reasonable  to  assume  at  least  27  technical  assistance  requests  a  year  are 
resolved  by  distance  support,  thereby  alleviating  unnecessary  travel  and  labor  associated 
with  “boots  on  deck”  support  by  an  ISEA.  The  cost  analysis  has  shown  that  DSHEL  will 
eventually  pay  for  itself  and  provide  cost  savings  over  the  life  cycle  of  the  HEL  platform. 
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4,  Research  Question  Findings 

The  following  research  questions  were  answered  by  this  capstone  report: 

•  How  will  DS  affect  the  overall  cost  and  risk  in  HEL  shipboard 
implementation? 

Over  the  life  cycle  of  the  HEL  program,  DSHEL  will  provide  cost  savings.  An 
annual  labor  and  travel  reduction  of  $54,413  per  year  is  realized.  Resulting  in 
$1.09M  over  a  20  year  life  cycle,  spread  across  30  ships.  Aggregate  risk  was 
shown  to  be  moderate  with  six  risks  identified:  one  low,  four  medium,  and 
one  high. 

•  What  type  of  infrastructure  is  required  to  adequately  perform  DS  for  HEL? 

In  analyzing  only  the  POI:  selected  sensors  (as  detailed  in  Chapter  III),  single 
rack  mount  server,  IP  KVM,  NAS,  and  system  monitoring  software. 

•  Are  there  any  existing  DS  frameworks  that  can  be  applied  to  DSHEL? 

No  existing  DS  framework  could  be  applied  to  DSHEL.  Other  frameworks 
were  analyzed  for  best  practices  and  then  tailored  to  fit  generic 
edge/peripheral  devices. 

•  Of  the  HEL  components,  which  information  is  the  most  important  to  collect? 
o  Total  intensity  over  time 

o  Total  energy  in  pulse 
o  Spectral  content 
o  Degree  of  polarization 
o  Angular  divergence 
o  Intensity  profile 
o  System  temperature 


B,  CONTRIBUTION  TO  BODY  OF  KNOWLEDGE 

The  contribution  to  the  BoK  consisted  of  three  topic  areas.  The  first  section 
discusses  the  distance  support  framework.  The  next  section  covers  the  functional  analysis 
that  was  completed  to  map  the  various  distance  support  functions  to  system/subsystem 
components  within  DSHEL.  The  final  section  details  the  DS  System  design  that  was 
developed  in  Chapter  IV. 
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1,  Distance  Support  Framework 

The  USN  has  a  very  eomplex  organizational  structure  as  well  as  many  systems  at 
different  phases  within  their  life  cycles.  A  robust  framework  was  needed  that  could 
account  for  all  USN  products  and  services,  while  adhering  to  the  many  policies  and 
regulations  that  affect  (directly/indirectly)  them.  In  order  to  complete  this  task,  a  systems 
view  of  the  concept  was  taken  and  current  architecture  frameworks  were  analyzed  for 
best  practices.  Ultimately,  a  DS  framework  had  to  be  constructed  from  the  ground  up. 

With  the  goal  being  to  deliver  quality  DS  from  the  information  and  data  collected, 
DS  was  broken  down  into  three  basic  elements:  PSP,  ESI,  and  POL  Each  of  these 
elements  play  an  important  role  in  this  goal  and  interacts  with  one  another  through  the 
use  of  SLAs.  Each  basic  element  can  further  be  broken  down  into  a  subset  of  elements. 
These  subsets  of  elements,  which  define  a  successful  organization,  are  people,  process, 
and  technology.  The  internal  interactions  of  these  subset  elements  are  governed  by  OEAs. 
Through  the  use  of  OEAs  and  SEAs,  quality  DS  is  provided  through  the  evidence  passed, 
generated,  and  shared  that  these  DS  elements,  collect,  verify,  record,  validate,  store, 
process,  filter,  log,  compress,  and  analyze.  This  is  done  in  order  to  produce  an  I2DE  set 
that  meets  the  minimum  data  picture  completeness  threshold. 

The  framework  offers  multiple  views  that  must  be  taken  when  providing  DS. 
These  views  start  with  the  POI  interfaces  and  slowly  expand  the  scope  to  POI 
interactions.  This  includes:  POI  classification  (independent  platform  vs.  guest  platform 
contained  within  host  platform),  DSX  configuration  (integrated — single-point  all 
inclusive,  encompassing — single-point  semi  inclusive,  distributed — multipoint  all 
inclusive,  distributed — multipoint  semi  inclusive),  enterprise  ecosystem  entities,  and 
global  environment  externalities. 
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Figure  109.  DS  Application  Context  Diagram 


2,  Distance  Support  Functional  Analysis 

The  functional  analysis  explored  in  chapter  IV  mapped  four  out  of  the  six  distance 
support  pillars  down  to  their  most  basic  of  functions.  This  was  done  using  the  IDEFO 
modeling  framework.  The  IDEFO  modeling  framework  shed  light  on  the  distance  support 
pillars  that  the  Navy  has  developed,  namely  that  they  might  be  structured  improperly. 
When  completing  the  functional  analysis,  the  results  indicated  that  although  the  Navy  has 
broken  out  the  distance  support  functions  into  six  individual  pillars,  the  Remote 
Diagnostics,  Remote  Repair  and  Validation,  and  Remote  Monitoring  pillars  are  a  subset 
of  the  Remote  Technical  Assistance  pillar. 

This  is  the  result  of  the  way  in  which  maintenance  and  repair  is  currently 
conducted  in  the  USN.  To  date,  the  USN  has  been  reluctant  to  allow  remote  connectivity 
and  repair  onboard  ship  due  to  the  desire  for  human  interface  to  ensure  accountability. 

Much  of  the  maintenance  is  driven  through  email  or  shore  based  databases  that  manage 
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logistic  functions  for  the  ship.  Verified  in  the  IDEFO  diagrams  in  ehapter  four,  all  major 
outputs  from  the  eontext  diagram  are  outputs  of  the  function  performing  remote  teehnical 
assistance  for  the  system.  All  other  functions  analyzed  only  provided  outputs  in  the  form 
of  feedback  to  the  function  of  providing  remote  technical  assistance. 

3.  Distance  Support  System  Design 

In  addition  to  the  functional  analysis  that  was  accomplished  in  chapter  four,  the 
ehapter  also  took  on  the  task  of  creating  a  notional  physical  architecture  for  a  generic  DS 
system.  The  design  analyzed  both  the  hardware  and  software  that  could  potentially  be 
involved  in  developing  the  DS  system.  This  allows  system  engineers  to  have  a  working 
prototype  from  whieh  eost  estimates  and  implementation  strategies  are  developed. 
Although  it  is  not  advisable  to  develop  a  standalone  system  rather  than  integrating  into 
the  POI,  it  is  useful  for  a  program  to  know  the  TOC  of  a  distanee  support  eapability. 

C.  RECOMMENDATIONS 

The  first  section  summarizes  evidenee  from  the  eapstone  to  support  the  need  for 
distance  support.  This  evidence  is  detailed  further  in  Chapters  V  and  VI  of  this  capstone. 
The  next  section  discusses  the  need  for  the  establishment  of  detailed  SLA/OLA’ s 
between  organizations  needing  to  develop  a  plan  for  distance  support.  The  last  section 
provides  recommendations  for  developing  the  distance  support  functions. 

1.  Design-In  Distance  Support 

Reiterating  the  findings  from  the  HEL  Master  Plan,  it  was  stated  that  there  would 
be  aequisition  ehallenges  in  fielding  a  laser  weapon,  given  the  limited  community  of 
subject  matter  experts.  Extending  this  original  challenge  of  aequisition  to  in-serviee,  it 
follows  that  the  sustainment  of  a  laser  weapon  has  equal  challenges  given  the  few  to 
many  relationship  of  supporting  these  systems  with  a  limited  community  of  subject 
matter  experts.  Integrated  distanee  support  serves  as  a  foree  multiplier  and  bridges  the 
gap  via  service  level  agreements,  to  provide  remote  access  and  faster  response  time  for 
issue  resolution  among  the  pool  of  support  resources  to  the  afloat  HEE  assets.  Cost 
savings  have  been  shown  based  on  legaey  and  modeled  technical  assistance  from  the 
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Fleet  in  leveraging  a  knowledgebase  of  SME’s  ashore  to  resolve  problems  remotely.  It 
was  shown  through  modeling  and  simulation  that  system  integrated  distanee  support  also 
has  the  potential  to  significantly  decrease  mean  down  time.  By  putting  complete 
diagnostics  data  into  the  hands  of  the  most  experienced  engineers  and  technicians  at  the 
onset  of  a  system  issue,  problems  are  resolved  faster.  The  reduction  in  mean  down  time 
dramatically  increased  Ao  without  modification  to  the  host  system.  Given  the  results 
from  M&S  show  a  shorter  duration  in  issue  resolution  time,  alongside  the  reduction  in 
travel  and  labor  cost,  it  is  the  recommendation  of  this  report  to  design  in  a  distance 
support  subsystem  to  the  high  energy  laser. 

2,  Establish  Service  and  Operational  Level  Agreements 

Without  communication  and  transmission  of  data,  DSHEL  would  not  function. 
DSHEL’s  entire  layout  and  key  principles  were  dependent  upon  the  sharing  and 
transmission  of  data  between  a  PSP  and  a  POL  As  a  result,  SLAs  and  OLAs  were 
paramount  to  establishing  and  maintaining  the  necessary  communication  paths  for  DS. 
SEAs  and  OLAs  work  together  in  order  to  facilitate  agreements  between  service 
providers  and  end  users  (SLAs)  and  internal  groups  within  an  element  (OLAs).  This  was 
the  key  description  of  the  aforementioned  PSP  and  POI  sharing  information  and  data. 
SLAs  therefore  proved  essential  to  set  up  data  transmission.  These  agreements  are  for 
products  and  services.  In  DSHEL’s  case,  they  were  for  the  transmission,  monitoring,  and 
receipt  of  data  as  well  as  the  implied  sub  categories  and  needs  inherent  to  those  functions. 
The  number  and  type  of  SLA  or  OLA  was  dependent  upon  the  portion  of  the  platform  in 
question  that  was  under  review.  It  is  the  recommendation  that  SLAs  and  OLAs  are 
established  in  order  to  accomplish  the  internal  and  external  communication  essential  to 
DS. 


3.  Redefine  Distance  Support  for  the  U.S.  Navy 

Previously  completed  analysis  indicates  that  the  current  DS  efforts  in  use  by  the 
USN  lack  certain  key  qualities.  The  preconceived  notion  was  that  DS  was  composed  of 
Six  Pillars.  This  belief  leads  to  the  misconception  that  all  pillars  are  equal  in  weight  and 
importance  and  that  they  evenly  share  responsibility.  However,  choosing  to  separate  DS 
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into  several  pillars  ereates  a  fraetured  environment  and  is  not  eohesive.  Also,  the  belief 
that  eaeh  sueeessive  pillar  is  just  as  important  as  the  last  adds  instability  to  the  DS 
environment.  DS  is  not  a  set  of  pillars  that  ean  be  segregated;  rather,  it  is  a  Serviee 
Oriented  Arehiteeture  that  takes  into  aeeount  (Service  Oriented  Architecture 
Organization  2013): 

•  business  value  over  technical  strategy 

•  strategic  goals  over  project-specific  benefits 

•  intrinsic  interoperability  over  custom  integration 

•  shared  services  over  specific-purpose  implementations 

•  flexibility  over  optimization 

•  evolutionary  refinement  over  pursuit  of  initial  perfection 

This  capstone  has  developed  a  DS  framework  that  elevates  the  discussion  of  how 
best  to  apply  Distance  Support  for  a  specific  POL  This  framework  takes  into  account  not 
just  what  is  needed  for  the  POI,  but  also  what  is  needed  for  the  ESI,  and  PSP.  This 
encompassing  approach  to  the  application  of  DS  as  a  service  is  a  more  comprehensive 
solution  to  the  larger  USN  life-cycle  support  philosophy.  It  is  the  recommendation  of  this 
capstone  that  the  USN  redefine  their  current  DS  methods  and  adopt  the  DS  framework 
outlined  in  this  capstone. 

D,  FUTURE  EXPLORATIONS 

The  following  section  describes  areas  of  future  work,  which  is  outside  the  scope 
of  this  research,  as  well  as  areas,  which  could  be  refined  by  further  analysis.  The  first 
section  discusses  the  need  for  mapping  the  current  DS  pillar  structure  into  the  DS 
framework.  The  next  section  brings  to  light  the  benefits  of  using  real  world  data  to 
support  the  modeling  and  simulation  and  the  cost  analysis  for  a  DS  system.  The  last 
section  calls  attention  to  further  research  that  could  be  done  to  explore  the  USN  big  data 
problem. 

1.  ePrognostics,  and  Self  Repair  and  Healing 

The  focus  of  this  capstone  was  on  the  application  of  the  first  four  pillars  of 

distance  support  to  HEL.  By  expanding  the  initial  focus  to  include  the  latter  two  pillars, 
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ePrognostics  and  Self  Repair  &  Healing,  is  expeeted  to  reveal  even  greater  eost  savings. 
Given  the  eurrent  eost  analysis  was  only  eapturing  the  reduetion  of  onsite  travel  and 
labor,  inelusion  of  the  last  two  pillars  would  result  in  the  failure  prevention  of  expensive 
HEL  subsystem  components,  thereby  adding  additional  material  cost  savings  and 
increased  uptime.  Subsequent  updates  to  system  requirements,  functional  analysis,  M&S, 
and  risk  analysis  should  be  investigated. 

2.  Vetted  Parameters  as  Inputs  to  Modeling  and  Cost  Analysis 

A  challenge  faced  in  this  study  was  the  immaturity  of  existing  HEL  systems  and 
real  world  in  service  engineering  and  maintenance  data.  This  was  overcome  by  the  use  of 
M&S,  as  well  as  comparative  and  composite  inputs  for  response  times  and  costs  from 
legacy  PEO  IWS  studies  for  other  weapon  systems.  As  the  HEL  goes  from  a  test  bed 
status  into  a  full-fledged  Program  of  Record  (PoR),  the  opportunity  will  exist  to  refine  the 
models  and  estimates  in  this  capstone  with  real  world  data.  These  sources  will  be 
contained  in  the  Navy-311  Help  Desk  database.  Command  Issue  Manager  (CIM),  and 
Maintenance  Eigure  of  Merit  (MEOM)  AWN  system.  The  methodologies  in  this  report 
were  presented  in  a  flexible  and  transparent  manner,  such  that  the  variables  could  be 
updated  for  future  studies.  As  it  was  necessary  to  use  composite  estimates  as  input 
parameters  due  to  classification  restrictions,  it  is  suggested  that  the  mean  down  time 
models  be  modified  and  analyzed  for  current  fielded  systems  to  assess  potential  impact  of 
integrated  distance  support.  It  is  the  recommendation  that  as  DSHEL  is  fielded  and 
sustained,  these  simulations  and  analyses  be  performed  annually  and  tailored  by  the 
program  systems  engineer  to  include  the  operational  failure  and  response  time  data.  This 
will  enable  the  PEO  and  in-service  community  to  make  HEL  system  sustainment  and 
modernization  decisions  based  on  data  which  includes  the  distance  support 
methodologies. 

3.  DS  Framework  Expansion 

The  DS  framework  focused  on  the  POI;  follow-on  work  to  expand  and  analyze 
the  PSP  and  ESI  in  depth  is  needed.  Within  the  PSP  element,  attention  is  needed  in 
developing  the  proper  resources  requirements,  infrastructure,  manning  levels,  associated 
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training  programs,  knowledge  management  tools,  and  product/serviee  feedbaek 
improvement.  The  ESI  element  would  benefit  from  future  researeh  and  development  into 
information  transport  mediums  and  infrastructure,  cybersecurity  challenges,  and  signal 
reconstruction/acquisition  techniques. 

4.  U,S,  Navy’s  Big  Data  Problem 

In  Chapter  I,  the  amount  of  data  generated  by  a  typical  Boeing  737  engine  was 
extrapolated  to  a  USN  Arleigh  Burke  Class  Guided  Missile  Destroyer  (gas  turbine 
engines  only)  and  then  compared  to  all  the  total  amount  of  information  contained  within 
the  Library  of  Congress.  It  was  surmised  that  a  typical  deployment  of  a  single  ship  lasting 
six  months  would  generate  438  times  more  data  than  that  of  the  entirety  of  the  Library  of 
Congress.  This  amount  of  data  only  accounts  for  the  gas  turbine  engines  alone  and  does 
not  include  the  rest  of  the  systems  on  board  of  the  ship  (radar,  communication,  weapons, 
mechanical,  network,  etc.).  While  data  filtering  can  account  for  80%  data  reduction 
(Porsche,  Wilson,  Johnson,  Tierney,  and  Saltzman  2014),  this  would  still  leave  87 
Library  of  Congress’  worth  of  relevant  data  to  be  analyzed  and  transported. 

As  the  USN  becomes  more  networked,  the  Internet  of  Things  (loT)  concept  may 
be  adopted  by  the  USN  and  become,  in  the  case  of  surface  combatants,  a  Ship  of  Things 
(SoT).  Research  and  development  in  the  area  of  big  data  and  data  science  needs  to  be 
increased  to  keep  the  USN  from  drowning  in  a  flood  of  its  own  data. 
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APPENDIX  A.  KPP,  KSA,  MOP,  AND  MOE 


A,  KPP  AND  KSA 

KPPs  are  defined  as  “Performance  attributes  of  a  system  considered  critical  to  the 
development  of  an  effective  military  capability.  A  KPP  normally  has  a  threshold 
representing  the  minimum  acceptable  value  achievable  at  low-to-moderate  risk,  and  an 
objective,  representing  the  desired  operational  goal  but  at  higher  risk  in  cost,  schedule, 
and  performance  (Defense  Acqusition  University  2014).” 

KPPs  are  not  to  be  confused  with  KSAs.  KSAs,  “A  Key  System  Attribute  (KSA) 
is  a  system  capability  considered  crucial  in  support  of  achieving  a  balanced 
solution/approach  to  a  system,  but  not  critical  enough  to  be  designated  a  KPP  (Defense 
Acqusition  University  2014).” 
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Figure  110.  “CDD  in  the  Acquisition/JCIDS  Process”  (from  ACQNotes  2014) 


KSAs,  and  KPPs,  are  developed  and  described  in  the  CDD  (Capability 
Development  Document).  This  document  is  developed  in  coordination  with  the  system’s 
development.  In  Figure  109,  the  general  process  for  the  development  of  this  and  other 
components  of  the  acquisition  process  is  displayed.  However,  it  was  necessary  to 
consider  the  standard  KPPs  and  KSAs  as  laid  out  by  the  JCIDS.  These  KPPs  and  KSAs 
and  how  they  were  applicable  to  DSHEL  are  listed  below: 
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1,  Mandatory  KPP — Force  Protection 

For  this  particular  KPP,  it  would  not  be  applicable  to  the  DSHEL  system.  “The 
intent  of  the  FP  KPP  is  to  address  protection  of  the  system  operator  or  other  personnel 
rather  than  protection  of  the  system  itself  (Survivability).”  (Department  of  Defense  2012, 
B-A-2)  In  order  for  this  official  call  to  be  made  it  would  be  necessary  for,  “the  Protection 
FCB  will  assess  the  FP  KPP,  or  Sponsor  justification  of  why  the  FP  KPP  is  not 
applicable,  for  any  document  with  a  JSD  of  JROC  or  JCB  Interest  (Department  of 
Defense  2012,  B-A-2).”  Considering  that  DSHEL  is  a  monitoring  and  reporting  system, 
it  was  considered  unlikely  that  force  protection  would  be  part  of  DSHEL. 

2,  Mandatory  KPP — Survivability 

Survivability,  which  deals  with  the  ability  of  a  system  to  maintain  working  status 
while  under  attack,  is  not  applicable  to  DSHEL.  “The  intent  of  the  Survivability  KPP 
includes  reducing  a  system’s  likelihood  of  being  engaged  by  hostile  fire,  through 
attributes  such  as  speed,  maneuverability,  detectability,  and  countermeasures;  reducing 
the  system’s  vulnerability  if  hit  by  hostile  fire,  through  attributes  such  as  armor  and 
redundancy  of  critical  components;  and  allowing  the  system  to  survive  and  continue  to 
operate  in  a  chemical,  biological,  radioactive,  and  nuclear  (CBRN)  environment,  if 
required.”  (Department  of  Defense  2012,  B-A-2)  The  individual  monitored  components 
that  compose  DSHEL  require  this  KPP;  however,  DSHEL  itself  would  not.  Individual 
components  reporting  to  HEL  have  potential  to  be  “engaged  by  hostile  fire;”  however, 
DSHEL  as  a  monitoring  and  reporting  system,  would  not. 

3,  Mandatory  KPP — Net-Ready 

The  Net-Ready  KPP  referred  to  “The  NR-KPP  is  applicable  to  all  documents 
addressing  IS  and  National  Security  Systems  (NSS)  used  in  the  automated  acquisition, 
storage,  manipulation,  management,  movement,  control,  display,  switching,  interchange, 
transmission,  or  reception  of  DOD  data  or  information  regardless  of  classification  or 
sensitivity  (Department  of  Defense  2012,  B-A-3).”  This  KPP  was  directly  related  to 
DSHEL.  One  of  the  primary  functions  of  DSHEL  was  the  transmission  of  information 
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between  the  POI  and  an  off-site  facility.  Therefore,  it  was  necessary  to  ensure  the  Net- 
Ready  KPP  was  included. 

4,  Mandatory  KPP — Sustainment 

Sustainment  KPPs  were  defined  as,  “The  Sustainment  KPP  and  two  supporting 
KSAs  (Reliability,  Operation  and  Support  (O&S)  Cost)  are  applicable  to  all  documents 
addressing  potential  acquisition  category  (ACAT)  I  programs.  The  intent  of  the 
Sustainment  KPP  is  to  JCIDS  Manual  19  Jan  2012  B-A-3  Appendix  A  Enclosure  B 
ensure  that  sustainment  planning  “upfront”  enables  the  requirements  and  acquisition 
communities  to  provide  a  system  with  optimal  availability  and  reliability  to  the 
warfighter  at  an  affordable  cost”  (Department  of  Defense  2012,  B-A-2).  Since  HEL 
could  potentially  become  an  ACAT  I  program  and  DSHEE  is  a  subsystem  component  of 
HEE,  there  exists  the  possibility  that  DSHEE  would  then  inherit  the  Sustainment  KPP. 

5,  Mandatory  KPP — Availability 

According  to  JCIDS,  the  Availability  KPP  gets  divided  into  Material  Availability 
and  Ao. 


a.  Mandatory  KPP  Subset — Materiel  Availability 

Eor  the  Materiel  Availability  portion,  “Materiel  Availability  is  the  measure  of  the 
percentage  of  the  total  inventory  of  a  system  operationally  capable,  based  on  materiel 
condition,  of  performing  an  assigned  mission.  This  can  be  expressed  mathematically  as 
the  number  of  operationally  available  end  items/total  population.  The  total  population  of 
operational  end  items  includes  those  in  training,  attrition  reserve,  pre-positioned,  and 
temporarily  in  a  non-operational  materiel  condition,  such  as  for  depot-level  maintenance, 
shipyard  repair,  etc.  Materiel  Availability  covers  the  total  life-cycle  timeframe,  from 
placement  into  operational  service  through  the  planned  end  of  service  life”  (Department 
of  Defense  2012,  B-E-3).  DSHEE  would  be  concerned  with  “Ao”  and  operational 
statuses  so  considered  this  to  be  an  applicable  KPP.  DSHEE  required  the  monitoring  of 
various  components  of  the  HEE  system  and  as  a  result,  cared  about  the  status  of  “materiel 
condition”  of  HEE  components. 
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b.  Mandatory  KPP  Subset — Operational  A  vailability 


Operational  Capability  is  the  seeond  eomponent  of  the  Availability  KPP  and 
ineluded,  “Operational  availability  is  the  measure  of  the  pereentage  of  time  that  a  system 
or  group  of  systems  within  a  unit  are  operationally  eapable  of  performing  an  assigned 
mission  and  can  be  expressed  as  (uptime/(uptime  +  downtime)).”  (Department  of  Defense 
2012,  B-E-3)  As  with  the  Material  Availability,  DSHEL  was  concerned  with  the  Ao  of 
the  HEE  system.  This  KPP  subset  represented  the  connection  between  availability  of  the 
system  and  the  more  specific  concern  of  the  availability  of  system  components  and  their 
status,  which  was  considered  to  be  a  key  component  to  DS. 

6,  Selectively  Applied  KPP — System  Training 

The  Training  KPP  encompassed,  “The  Training  KPP  is  applicable  to  all 
documents  addressing  potential  ACAT  I  programs.  The  intent  of  the  Training  KPP  is  to 
ensure  that  training  requirements  are  properly  addressed  from  the  beginning  of  the 
acquisition  process,  in  parallel  with  the  planning  and  material  development,  and  updated 
throughout  the  program’s  Acquisition  Eife-Cycle.”  (Department  of  Defense  2012,  B-E-3) 
As  stated  previously  in  the  Sustainment  KPP,  if  DSHEE  were  to  be  considered  an  ACAT 
I  program,  this  KPP  would  be  necessary.  Training  should  be  considered  to  be  a  potential 
requirement  for  the  DSHEE  users. 

7,  Selectively  Applied  KPP — Energy  Efficiency 

The  Energy  KPP  includes,  “The  Energy  KPP  is  applicable  to  all  documents 
addressing  systems  where  the  provision  of  energy,  including  both  fuel  and  electric  power, 
to  the  system  impacts  operational  reach,  or  requires  protection  of  energy  infrastructure  or 
energy  resources  in  the  logistics  supply  chain.”  (Department  of  Defense  2012,  B-A-3). 
This  particular  KPP  was  not  considered  to  be  important  to  include  in  DSHEE  because 
from  the  perspective  of  power  usage,  DSHEE  is  not  a  major  component. 
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8,  Mandatory  KSA — Reliability 

The  Reliability  KSA  states  that,  “Reliability  is  a  measure  of  the  probability  that 
the  system  will  perform  without  failure  over  a  specifie  interval,  under  speeified 
conditions.  Reliability  shall  be  sufficient  to  support  the  warfighting  capability 
requirements,  within  expected  operating  environments.  Considerations  of  reliability  must 
support  both  availability  metrics.”  (Department  of  Defense  2012,  B-E-3).  This  particular 
KSA  was  applicable  to  DSHEL  as  it  was  a  general,  all-encompassing  statement  of  the 
need  for  any  system  to  perform  the  way  in  which  it  is  designed  to,  whenever  called  upon 
to  do  so. 


9,  Mandatory  KSA — Operations  and  Support  Cost 

The  Operations  and  Support  Cost  KSA  was  described  as,  “O&S  Cost  metrics 
provide  balance  to  the  sustainment  solution  by  ensuring  that  the  O&S  costs  associated 
with  availability  and  reliability  are  considered  in  making  decisions.”  (Department  of 
Defense  2012,  B-E-3)  As  well  as,  “Costs  are  to  be  included  regardless  of  funding  source 
or  management  control.  The  O&S  value  should  cover  the  planned  life  cycle  timeframe, 
consistent  with  the  timeframe  and  system  population  identified  in  the  Materiel 
Availability  metric.”  (Department  of  Defense  2012,  B-E-3)  Operations  and  Support  costs 
were  considered  to  be  inherent  to  establishing  a  new  system,  including  DSHEE. 
DSHEL’s  constant  monitoring  and  data  transmission  would  add  to  the  need  for  this  KSA. 
Costs  from  data  storage,  transmission,  SME  representatives,  and  facilities  would  all 
contribute  to  this  KSA. 

B,  MOP  AND  MOE 

MOEs,  are  defined  as  “the  data  used  to  measure  the  military  effect  (mission 

accomplishment)  that  comes  from  the  use  of  the  system  in  its  expected  environment.  That 

environment  includes  the  system  under  test  and  all  interrelated  systems,  that  is,  the 

planned  or  expected  environment  in  terms  of  weapons,  sensors,  command  and  control, 

and  platforms,  as  appropriate,  needed  to  accomplish  an  end-to-end  mission  in  combat” 

(Defense  Acqusition  University  2012).  Therefore,  the  MOEs  would  be  the  resultant  data 

from  the  testing  of  the  DS  system  with  respect  to  the  HEE  platform.  Suggested  data 
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collection  included:  thennal  testing,  vibrations  testing.  Kbps  and  data  size  data,  SME 
access  and  availability  data,  and  frequency  of  data  transmission.  MOPs  are  defined  as 
“System-particular  peifonnance  parameters  sirch  as  speed,  payload,  range,  time-on- 
station,  fieqitency,  or  other  distinctly  qrrantifiable  performance  featiues.  Several  MOPs 
may  be  related  to  the  achievement  of  a  particirlar  Measme  of  Effectiveness  (MOE).” 
MOPs  woirld  be  reflective  of  the  performance  reqiruements  (Defense  Acqirisition 
University  2012).  As  a  resirlt,  based  on  the  sirggestions  made  for  performance 
reqirirements  above,  MOPs  woirld  focus  on  data  transfer  as  well  as  the  POL  MOPs  woitld 
be  focused  on  the  actual  fieqirencies,  temperatmes.  Bps,  that  woirld  be  again  linked  to  the 
MOEs  for  data  collection.  As  an  example  of  a  MOE  and  a  MOP  bemg  part  of  the  KPP, 
and  developmental  process,  the  following  example  from  JCIDS  was  considered  (Table  34 
coiutesy  of  JCIDS  table  B-F-1,  “NR-KPP  Developmenf’); 


Table  34.  “NR-KPP  Development”  (from  Department  of  Defense  2012,  B-F-1) 
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Figure  111.  Relationships  between  Requirements,  KPPs,  MOPs,  and  MOEs 


Table  34  and  Figme  110  gave  an  example  of  how  requirements  and  KPPs  are 
linked  to  MOEs  and  MOPs.  The  KPP  stood  as  the  main  need  for  the  system,  while  the 
MOE  and  MOP  gave  support  to  and  classification  or  credence  to  the  existence  of  the 
KPP.  As  the  Key  Perfoimance  Parameter  would  be  representative  of  “attributes  of  a 
system  considered  critical,”  (Department  of  Defense  2012,  B-F-1),  the  diagram  above 
emphasizes  the  connection  between  what  the  focirs  of  the  functional  and  performance 
reqirirenients  woirld  be,  and  how  the  KPPs  woirld  logically  reflect  the  same  areas.  These 
figiues  detailed  the  domino  effect  of  reqiruements  writing.  The  fimctional  reqiruements 
are  linked  to  the  performance  reqrrirements.  Tlrese  reqirirernents  dictate  and  mfluence  the 
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KPPs  which  then  are  verified  and  measured  by  the  MOEs  and  MOPs.  These  figures 
underlined  the  importanee  for  elarity  and  earefully  worded  language  that  was  detailed 
previously  in  this  ehapter.  Keeping  requirements  elear  has  a  ripple  effeet  on  the 
subsequent  KPPs,  KSAs,  MOEs  and  MOPs.  Requirements,  KPPs,  KSAs,  MOEs,  and 
MOPs  work  in  a  linked  proeess  that  requires  balanee  and  systematie  eollaboration. 
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APPENDIX  B.  MODEL  PARAMETERS 


The  following  data  is  representative  of  the  modeling  and  simulation  effort 
performed  as  part  of  this  effort.  The  ineluded  data  tables  directly  exported  from 
ExtendSim  for  each  of  the  three  models.  While  the  model,  in  its  most  flexible  form,  is 
available  from  the  SE  Department  at  the  Naval  Postgraduate  School,  this  data  collection 
shall  serve  as  a  backup  for  the  data,  should  the  original  files  be  lost. 
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Sends  each  kern  to  a  selected  output 


1  ox  1 

I  Cancel  1 


"Specify  selection  conditions - 

Select  output  based  on'  (random 
□Use  block  seed  |51 


"Select  options - 

If  output  IS  blO^ed:  |item  wm  K» 

□  Predict  the  path  of  the  item  before  k  enters  this  block 


□  Show  probabilities  on  icon 


8/ock  type  Decision 


[90]  Select  Item  Out  <ltem> 

[  To  Stock  Pwb^lr  Thtpughpie 


1 

1  OntcarofSlj 

oo 

2 

Isalect  Itom  InfSO) 

01 

205 

ISO) 

Select  Item  Out 

<ltetn> 

ISO) 

Select  Item  Out 

<ltem> 
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[51]  Select  Item  Out  <ltem> 

Options  I  Item  Animation  |  Btocfc  Animation  |  Comments  | 


Sends  each  item  to  a  selected  output  ) 

I  Cancel  { 


■  Specify  se  iection  conditions - 

Select  ourtput  based  on  | random  J 

□Use  Wock  seed  [52  | 

"Select  options - 

If  outputls  blocked;  litem  will  was  for  blocked  output  J 
□Predict  the  path  of  the  item  before  it  enters  this  bfock 
□Show  throughput  on  icon 


loBlocv  ProboMlv  Throuatiput 

1 

2 

>•>.*■.  .-j-r oe 

S«*ect  itom  infSO)  02  •I’i  ' 

-J 

Equal  Probabilities  | 


□Show  probabilities  on  icon 


Biock  type  Oecision 


[SI] 

SefecI  Item  Out 

<llem> 

f  To  Block 

PiobaWty 

Throughput 

'P'mC.  Uro«r 

OS 

20M 

2 

[Saed  Itevn  ln(SS] 

02 

a67 

[SI) 

SefecI  Item  Out 

<ilem> 

[61J 

Select  Item  Out 

<ltem> 

[62]  Activity  <item> 

Annabon  |  Comments 


Process  [  cost  |  ^utdown  |  Pi^nyt  ]  Results  |  Contents  |  item  AnimatKin  | 


Processes  one  or  more  Hems  simultaneously: 
outputs  each  Hern  as  soon  as  it  is  finished 


OK 


Cancel 


'Define  capacrty 
Maximum  items  in  activity:  |i~ 


Specify  processing  time  (delay) 

Delay  Is  Ispeafied  by  a  distnbutian  J 

Dislrlbulion:  | Lognormal  ~ 


Delay  (D):  1:3  74833777  |ttme  unite 


Mean 
Sid  Dev: 


ET 


Plot  Sample 


Location.  ^ 


□  Use  block  seed  ^ 


"Define  other  processing  behavior 
□  Simulate  muttitaslong  activity 

Useshifl.  j  J  □Preemptwhenblockgoesoff shilt 


Bfock  type  Residence 
[62]  Activity  <ltem> 
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[92]  Activity  <}lem> 


[53]  Activity  <tteni> 

fliock  Anynabon  |  Comment* 


Process  I  Coat  |  Shutdown  |  Preempt  |  Reautt*  [  Content*  |  ttem  Antmatton  I 


Processes  one  or  more  Kerns  simultaneously: 
outputs  each  item  as  soon  as  it  is  finished 


OK 


Cancti 


'  Define  capecrty  - 

Maximum  items  in  acbvity:  ^ 


‘Specify  processing  time  (delay) 

DelayiS'  |6pect5ed  by  a  diatnbution  J 


OiSiribulion;  [Lognoim^ 
Mean 


K 


Std  Dev: 


if 


Delay  (D):  \:<i  583686351  time  units 


Plot  Sample  | 


Location:  ^ 


Q  lise  block  seed  |5K 


*  Define  other  processing  behavior  * 
[^Simulate  multrtaskeig  activity 
Use  shift  ] 


QPreempt  when  block  goes  off  shift 


Biock  type  Residence 


[53]  Activity  <ltem> 


[53]  Activity  <ttem> 
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Intanmvai  Ttm4 

ifl**  Htni* 

l7.rS86S2468 

OIS 

21.C»5<9S92 

006 

2e.48ai«sta6 

00 

2».3S3tt3riS 

096 

$3.228200602 

106 

$7.003077886 

206 

48.887888888 

366 

44  822832003 

406 

48.687709137 

64 

32.d02M622 

56 

M.41 7483364 

66 

80.282340387 

606 

64.147217471 

7  45 

68.01 2084M4 

015 

71.878971636 

600 

79.7418*8721 

43 

79.606729800 

51 

83.471602808 

415 

87.338479972 

43 

91.201357006 

41 

8i4l6C2Mt98 

25 

90.931111223 

20 

102.79088031 

235 

i06.omoa8 

106 

110.02074247 

1  7 

114.38061906 

1 

116290*9664 

1  5 

122.12037372 

106 

129.98029061 

00 

129  80012788 

05 

133.71900497 

05 

137.97988206 

04 

141.44479914 

01 

149.30863623 

006 

148.17401331 

025 

193  03839039 

02 

196.90426748 

015 

160.78814406 

006 

164  63402164 

006 

168.49689073 

01 

172.38377981 

0 

176.22869288 

01 

180.09392998 

0 

103.90840706 

0 

167  62328414 

0 

191.68816123 

006 

199.90303631 

0 

19941791938 

0 

203  28279246 

0 

207.14766906 

006 

I&4|  Activity  <lte«n> 

I  Block  Animaton  1  Comments  1 
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[S4]  Activity  <lteni> 


[54]  Activity  <lt«m> 

[55]  Select  Item  Out  <ltem> 

Options  I  Item  Animation  |  BlocK  Animalion  |  Comments  | _ 

I  OK  I 

Sends  each  Kern  to  a  selected  output  ^  * 

i  Canoel  1 

r  Specify  selection  conditions 

Select  output  based  on:  [random  J 

□  Use  block  seed.  )56  1 

r  Select  options 

If  output  Is  blocked'  i7  em  wiw  wa«  7] 

□Predict  the  path  of  the  item  before  it  enters  this  block 
□Show  throughput  on  icon 


To  Bloc*  ProbAMty  TrtfOugtiput 

1 

2 

i:  08 

RMCRvAevtrrt  0  2 

iO 

fequ^l  ^fobabil^s'n 

□Show  probabilities  on  icon 


Sfock  typo  Doasion 


[661 

SelecI  Item  Out 

<ltem> 

[  To  Block 

PtoMiiftr 

Thfowflhput 

1 

j 

08 

77': 

2 

[RMC 

02 

548 

[66| 

Select  Item  Out 

<ltem> 

[66] 

SelecI  Item  Out 

<ltem> 

[66]  Select  Item  In  <nem> 

Options  I  Block  Animation  |  Comments  ] 


Selects  an  input  and  outputs  its  item  _ 

rCancer] 

"  Specify  selection  rule  - 

Select  input  based  on:  [merge  J 


’  Select  options  a nd  report  throughput 


□Show  throughput  on  icon 


rrerrfihxk 

Thnucnnut 

0 

P-rr*-.- 

1 

Pin  OnbeordfSI] 

487 

2 

RMCNwdPwKS 

286 

S _ 

Block  type  Decision 

[56]  SelecI  Item  In  <nem> 
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[56]  Select  Item  In  <Kem> 


Woftcsheel  Dialogs 


Pfondcek 

ThroLtfiput 

0 

Hart 

r063 

1 

Part  Onbcani(6l] 

46r 

2 

PMC  HMOPadtS 

2es 

(831 

Select  Item  Out 

<lleni> 

Sends  each  Rem  to  a  selected  output 


I  OK 


Cancel 


’Specify  selection  conditions  ' 


Select  output  based  on:  Ifarvdom 
QUse  block  seed  [B4 


'Select  options  ' 

If  output  is  blocked  [^i^n 

QPredict  the  path  of  the  item  before  R  enters  this  block 


QShow  probabilities  on  icon 


Biock  type  Decision 


[B3)  Select  Item  Out  <ltem> 

Teftoctc 


Scicvt  itfHTi  Ir^aS) 


09 

01 


Thioughpu 


[83]  Select  Item  Out  <ltem> 


[83]  Select  Item  Out  <ltem> 
|86]  Select  Item  In  <Kem> 


Options  I  Block  Animation  |  Comments 

Selects  an  input  and  outputs  Its  Item 


'Specify  selection  rule 


Select  input  based  on;  | merge 


Cancel 


'Select  options  and  report  throughput 


QShow  throughput  on  icon 


Biock  type  Decision 


[86] 

Select  Item  In 

<ltem> 

[86J 

Select  Item  In 

<:ltem> 

FcomBcck 

TtvooeTpyt 

0 

'oijicr  Re  Attend 

ies& 

1 

Saicr  Atterpt  Reo 

less 

2 

RMC  Re-Aitertpt 

er 
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(104]  Activity  <ttem> 

I  Btock  Animation  |  Comments  | _ _ _ _ 

Process  |  Cost  [  ^uttfown  |  Prxmpt  |  Results  |  Contents  |  ttem  Antmatwn  ) _ 

Processes  one  or  more  Hems  simultaneousiy;  I  ~l 

outputs  each  item  as  soon  as  it  is  finished  |  Cancel  1 


~[>efine  capacity 
Maximum  items  in  activity  |i~ 


Specify  processing  time  (delay) - 

Delay  is*  Ispecified  by  a  diatnbutior>  J 
Distribution;  Iftoimai  ~ 


Delay  (0):  iFift  92471789  |tme  units 


Mean: 
Std  Dev: 


Plot  Sample 


Q  Use  bkKA  seed  [l05 


(104]  Activity  <llain> 


(104]  Activily  <ltem> 

(105]  Select  Item  Out  <ltem> 


(105]  Select  Item  Out  <Rem> 


1  TeOlock 

Ttiroughput 

1  IlSgA 

095 

2  U»i»ctllimlrt1S4| 

oos  i: 

(105]  Select  Item  Out  <Nem> 
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[105]  Select  Item  Out  <Rem> 


Woffcstieet  Dialogs 


[106]  Select  Item  Out  <Rem> 

Options  [  Item  Animation  |  Bktcfc  Animation  |  CommerO  | 


Sends  each  Mem  to  a  selected  output  |  ' 

I  Cancel  | 

"Specify  selection  conditions - 

Select  output  based  on'  Irandom  J 

Q  Use  block  seed:  [l  07  ~] 


"Select  options 


If  output  is  blocked*  [I'eoi  W  ^  * 

QPredict  the  path  of  the  item  before  it  enters  this  block 
QShow  throughput  on  icon 


ToBloc^  ProbaMty  Throughput 

1 

09  -.h: 

2 

->«th»inlr<1t2|  01  '.9 

ED 

Equal  ProbabiUbes  j 


QShow  probabilities  on  icon 


B/ock  type  Deds/on 


(108) 

Select  Item  Out 

<Mem> 

1  ToBtock  PnbaWHr  Thraughout 

|106| 

^jrt  ’.rBoart  1C ' 

Upm  11^112) 

Select  Item  Out 

os  ’A*. 

01  12S 

<ltem> 

11061 

Select  Item  Out 

<Mem> 

1107) 

Select  Item  Out 

<Mem> 

Options  I  Item  Animation  |  Block  Animation  |  Comment^ 


Sends  each  Mem  to  a  selected  output 


I  OK  I 

I  CafKei  "1 


'Specify  selection  conditions 
Select  output  based  on  jrandom 
Q Use  block  seed,  ftps 


"Select  options 


If  output  is  blocked  li  em  ww  wan  >w  T 

QPredIct  the  path  of  the  item  before  t  enters  this  block 
□Show  throughput  on  icon 


roBloc* 

ProbeWly 

IhrauahSMt 

1 

oe 

2 

'>*<til»fnlr(1121 

02 

?11 

to 

^qual  ^robablilbesn 
□  Show  probabilities  on  icon 

Stock  type  Dedsion 

(107)  Select  Item  Out  <Rem> 


I  ToBlocti  PiobebWr  Thioughput 

~  1  I  'O?'  or  0  6 

2  02  21t 

[107]  Select  Hern  Out  <ttem> 
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{107]  Select  Hem  Out  <Rem> 


Worksheet  Dialogs 


[108]  Acttvtty  <llem> 

I  Block  Anmatwn  |  Commer^ts 


Process  |  cost  |  Shutdown  |  Pnsempt  ]  Results  |  Contents  |  ttem  Animattor^  ] 


Processes  orte  or  more  Hems  sImtRtaneously: 
outputs  each  item  as  soon  as  H  is  finished 


OK 


Cancel 


’Defir»e  capecrty  - 

Maximum  items  in  activity;  R~ 


'Specify  processing  tin>e  (delay) 

DelayiS'  jspecifieo  fay  a  distnOution  J 
Distribution;  jLoflnorrnai 


Oelay(D):  |&  8235827^ lime  units 


Mean. 
Std  Dev; 


H 


Plot  Sample 


Location:  ^ 


nitee  block  seed  [109 


‘  Defirie  other  processing  behavior  ' 
[^Simulate  multitasking  activity 
Use  shift  I 


QPreempt  when  block  goes  off  shift 


Biock  type  Residence 


[108]  Acttvtty  <ttem> 


[108]  Activity  <ttem> 


(108)  Items*  Distribution 
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Interamval  Timi 

ifIN 

I5r2i4as4rs 

106 

348974«81S6 

2 

441S3447B31 

490 

S.3368427S07 

636 

S29«S4071S3 

7 

Msoisesssa 

8 

6.101  TSeSSM 

926 

9  02S3S46211 

67 

9  9449329687 

76 

10.e66»30986 

67 

11.766126924 

6.1 

12708726491 

6  76 

13  631324486 

436 

14.992822427 

41 

19.474920394 

306 

16.3861 18362 

256 

17.317716329 

2  75 

16.233014297 

22 

19.160912269 

1  75 

20.0«2910232 

1  S 

21  0041062 

126 

21.929706166 

1  46 

22.647304139 

056 

23  768902103 

07 

24.68090007 

07 

29.612096036 

02S 

26.933896006 

04 

27.499293873 

03 

26376e91941 

01 

29  298469906 

04 

30.220087676 

036 

31.141689644 

02 

32.063383611 

016 

32.984661779 

01 

33  906479746 

01 

34.828077714 

026 

39.748679662 

0 

X.(712T3C4S 

0 

37  882871617 

01 

36.914469984 

01 

39.436067992 

0 

40.30766992 

0 

41.279263467 

016 

42.200861499 

01 

43.122499422 

0 

44.04409738 

0 

44.668699398 

0 

49  887293320 

0 

46.808891293 

0 

47.73044626 

01 

(109)  Actrvtty  <ltem> 

^ck  Animation  )  Comments 


Process  [  Cost  [  ^uMown  |  Preempt  |  Reautts  |  Contents  |  Hem  Animation  | 


Processes  orM  or  more  Mems  sknultarwously; 
outpuls  each  item  as  soon  as  it  is  Teiished 


OK 


Cancel 


'Cyefine  capacity 
Maximum  items  in  acbvity: 


3 


'Speofy  processing  time  (delay) 

Delay  is  (specified  Py  a  distnbobon  J 
Distribution:  (Lognormal 


3 


Delay  (D);  (l6  491157651  time  unite 


Mean 
Std  Dev: 


ET 


Plot  Sample  | 


Location  |d~ 


Q Use  block  seed  [llQ 


’Define  other  processing  behavior  ' 
^Simulate  muttitaskmg  activity 
Use  shift  I 


Q^eempt  when  block  goes  off  shift 


Biock  type  f?es;dence 
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[109]  Activity  <nem> 


[109]  Activity  <ttem> 
[109]  Hems' Diitribution 


Ketnv'  Oistnbution 


[109]  Hems*  Distribution 


intonmval  Tim* 

iHlik  eBin* 

■■ 

rrs 

lojneTMor 

029 

11.ri2BS2042 

0  45 

12.SS33M0n 

08 

13.3a4144112 

1  1 

14.254000147 

215 

iionsMiei 

2.3 

19.»1<41221« 

31 

1€.rS71«e2S1 

37 

17.SOT>a<2IO 

90 

18.438600321 

43 

18.27843UM 

55 

2012018238 

52S 

20.960848428 

615 

21.00170448 

545 

22.843480488 

556 

23  48321883 

83 

34.323872808 

47 

29.184728988 

545 

26  008484634 

435 

26.846340888 

3  75 

27.686886704 

386 

28.927782738 

335 

29.368a08r74 

32 

30.208(884808 

285 

31060000843 

225 

31.880778878 

21 

32  731632813 

1  4 

33  972388848 

1  28 

34413044888 

085 

38.283801018 

1  05 

38  084867082 

08 

36.936313087 

05 

37.778089122 

06 

38618829187 

02 

39  497881192 

035 

40  299337277 

03 

41  138083261 

03 

41.979849298 

01 

42.820609331 

025 

43  681361368 

0 

44.902117401 

01 

49.342673438 

01 

4618882947 

01 

47  024389908 

006 

47  86814194 

0 

48  706897578 

006 

49  94669361 

005 

90.387409648 

01 

51  22816668 

008 
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[110]  Actrvrty  <Heni> 

I  Block  Animation  |  Comments  | _ _ _ _ 

Process  |  Cost  ]  Shutdown  |  Preempt  [  Resuttt  [  Contents  |  Item  AnimatKin~~| 


Processes  one  or  more  items  simultaneously: 
outputs  each  item  as  soon  as  it  Is  finished 


OK 


‘Define capaccty 
Maximum  items  in  activity  f 


'Specify  processing  time  (delay) 


Delayis'  [specifved  by  a  distnbution  J  Oelay(O):  jl  I  89888746 1 time  units 

- 3 


Distributoon:  | Normal 
Mean.  \\2 


Std  Dev: 


Plot  Sample 


□  Use  block  seed  |ll1 


'Define  other  processing  behavior  ' 
□Simulate  muttrtaskeig  activity 
Use  shill.  I 


^  □Preempt  when  block  goes  off  sfkR 


Bfock  type  Residence 


[110]  Activtiy  <llafyi> 


[110]  Activity  <Kem> 

[111]  Select  Item  Out  <Rem> 

Options  I  [tern  Animation  |  Block  Animation  |  Comments  | 

Sends  each  item  ti>  a  selected  output 


Block  type  Dedsiop 
[111]  Select  Hem  Out  <Rem> 

ITo&ecit  Pwb^ir  Tiiwmiiniie 

Oi  110« 

tSEAftr-Atittrct  01  tn 

[111]  Select  Hem  Out  <Rem> 


Specify  selection  conditions  ' 


Select  output  based  on:  [random 
□  Use  block  seed 


112 


Select  options - 

tfoutput  IS  blocked  win  vr« 


□Predict  the  path  of  the  item  before  a  enters  this  block 


□Show  probabilities  on  icon 


I  OK  I 

I  CarKtl  I 
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[111]  Select  ttem  Out  <ttem> 

[112]  Select  Item  In  <ltem> 

Options  I  Block  Antmatton  |  Comments  ] _ 


Selects  an  Input  and  outputs  Its  Item  |  * 

I  Cancel  ] 

‘Specify  selection  rule  - 

Select  input  based  on:  |n%erge  J 


‘  Select  options  and  report  throughput 


QShow  throughput  on  icon 


rror£<ock  Throughout 

0 

be*  Hei-.r-cPjiT  '30^ 

1 

2 

^A't0n»ard|107|  21' 

iSCA  N»0d  ^vt(1  lib 

2D_ 

l 

Biock  type  Decrsron 


[1121 

Select  Item  In 

<ltem> 

[112] 

Select  Item  In 

<ltem> 

Ror©cck 

TtVOU^VIlt 

0 

StLA  Rc<w>«  Pah 

BSI 

1 

^ait0rMatd(t07) 

211 

3 

ISEA  Heed  Pwt(1 

1» 

[139]  Select  Item  Out  <ltem> 


Options  I  Item  Anenahon  j  Bk>c*c  Animation  |  Comments  j 


Sends  each  tern  to  a  selected  output  * 

I  CafKei  1 


Specify  selection  conditions 

Select  output  based  on:  {random  J 

□Use  block  seed  |i40  | 

13 

eiea  options 

f  output  IS  blocked  |<  Rinwmvfdii  -  "I  '  V.  V  .] 

^Predict  the  path  of  the  item  before  it  enters  this  block 

I^Show  throughput  on  icon 

fo  Btoc«.  Protaataier  T>HouoHpia 

0  2  ^ 

Se«etlMfr>lr043)  08  88 

3D 

Equal  Probabiiaiea  1 
^Show  probabilities  on  icon 

Biock  type  Decision 

[139]  Select  ttem  Out  <Rem> 


f  To  Block  Piob«ei8r  ThfouahpMt 

rSir  (r^ie4< 

0  2 

2  1 

Sotoct  «m  ln(142} 

oa  SB 

1139) 

Select  Item  Out 

[139) 

Select  Item  Out 

<Rem> 
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[142]  Select  Item  In  <ltem> 

Options  I  BloOt  Animation  |  Comments  | 


1  OK  I 

Selects  an  input  and  outputs  its  Hern 

1  Cancel  I 

'Specify  selection  rule 

Seltcl  Input  based  on:  | merge 

“3 

’  Select  options  and  report  throughput 


QShow  throughput  on  icon 


FlCfTfiloCk 

0 

HM.  We  Are'rt< 

4“- 

1 

2 

HM:  AMmptKffp 
ISEt*  R*-AMrr«( 

“ft 

l 

Block  typo  Dod&on 


1142) 

1142] 

Select  Item  In 

Select  Hem  In 

<Hem> 

<nem> 

rimirtorti 

tiraMlwit 

D 

RUC 

4ei 

1 

RMC  ABempt  Rep 

roi 

2 

13EA 

ea 

[156]  Activity  <ltenn> 

I  Stock  Anenetton  j  Comment* 


PrcKess  I  Cost  |  Shutdown  |  Prompt  ]  Results  |  Contents  |  Item  Animation  ~| 


Processes  one  or  more  Hems  simultaneously: 
outputs  each  Hem  as  soon  as  It  is  fvushed 


OK 


Cancel  | 


"Define capecfty  - 

Maximum  items  in  activity  [F 


"Specify  processing  time  (delay)  - 

Delay  IS.  Ispeaheo  by  a  distnouiion  J 
OistnbutKin;  [ftormai 


Delay  (D):  |i 9  403707931  time  units 


Mean: 
Std  Dev; 


12 


J 


Plot  Sample 


Q  Ose  block  seed  |i57 


"Defirve  other  processing  behavior  ' 
[^Simulate  multitasking  activity 
Use  shift  I 


"31  Q  Preempt  when  block  goes  off  shift 


Bfock  type  Residence 


[156]  Activity  <ltem> 


[156]  Activity  <ltem> 
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[158]  Select  Item  Out  <ltem> 

Options  I  ttem  Animation  |  Block  Animation  |  Comments  | 


Sends  each  item  to  a  selected  output  i .  - J 

I  Car>oeM 

'Specify  selection  conditions - 

Select  output  based  on  [random  J 

□  Use  block  seed  |159  | 


'Select  options 


If  output  IS  blocked.  [  ~  •  '  ■!  ^  UUlf 

□Predict  the  path  of  the  item  before  it  enters  this  block 
□Show  throughput  on  icon 


To  8ioc«  Probobtlty  fnfcuaitout 

1 

2 

toj'.mi-.-:  0  6 

.?ec*ilefnlr<ieai  01 

50 

J 

Equal  Pfobabilibes  j 


□Show  probabilities  on  Icon 


Bfock  type  Oecrsion 


[1SS] 

Select  Item  Out 

<ltem> 

1  to  Stock  PtobaMw  Throuaheui 

J 

|1S8] 

Pact  Onooard(lSe^ 
Seisct  ttomlr^ie4t 

Select  Item  Out 

os  .V 

01  4 

<Rem> 

I1S8I 

Select  Item  Out 

<llein> 

[1691 

Select  Item  Out 

(169)  Select  Item  Out  <ltem> 


f  Tofitock  Piofaitolte  Threuaheut 

in 

ISE*  Dfoe’  or 

06 

2  1 

betKl  itefn  Irt(ie4t 

02  12 

[169] 

Select  Item  Out 

<ltem> 

11591 

Select  ttem  Out 

<ltem> 
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(160)  Actrvity  <tteiTi> 


I  Block  Animation  |  Comments  | 


Process  [  Cost  |  ShuiOown  |  Preempt  ]  Results  |  Contents  |  ttem  Animattor^  ] 


Processes  one  or  more  Hems  simultaneously; 
outputs  each  item  as  soon  as  it  is  finished 


OK 


‘C>ef)r>e  capaccty 
Maximum  items  in  actrvity  ^ 


'Specify  processing  time  (delay) 


Delay  IS'  [specified  by  a  distnOution  J  Delay  (0);  |l  t  47706423 1  time  units 


Dtstributoon:  [Lognormal 

Mean.  [i2 
Std  Dev: 


Plot  Sample 


Location:  [cT 


[~|Use  block  seed  |i61 


'Define  other  processing  behavior  ' 
□Simulate  multitasking  activity 
Use  shift  I 


□  Preempt  when  block  goes  off  shift 


Block  type  Residence 


(ISO)  Activity  <llam> 


[160]  Acttvity  <ltefn> 
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Worksheet  DUIoqs 


intMmval  Ttmi 

ifTN  HBm* 

"  1 9ro4asMit 

0  IS 

29<«e747r2l 

OSS 

3.SS28B39924 

196 

4.9S»1132126 

466 

599S»24S2e 

5  76 

fi.ssiaeissai 

04 

79477700733 

91 

09439900935 

03 

9  9402093136 

91 

10.939420934 

64 

11.952947794 

565 

12.928906974 

S36 

13.925096195 

51 

14.921309415 

39 

19.917094639 

386 

16.913743969 

406 

17.909993079 

32 

19906162299 

1  7S 

19.902401916 

2 

20.499920739 

145 

21 .494839997 

086 

22.491099177 

1  6 

23.497279397 

065 

24  493497617 

0  76 

29.479719a38 

066 

26.479936059 

056 

27>4721 69270 

036 

26.4993r449a 

0  45 

29.494993718 

0  25 

30490812938 

056 

31.497032198 

025 

32.453251379 

016 

33.449470999 

006 

34.44598982 

006 

39.44190904 

01 

36  43812826 

01 

37.43434748 

01 

36.430690701 

016 

39.426789921 

01 

40.423009141 

006 

41.419224391 

006 

42.415443981 

0 

43.411962902 

0 

44.407882022 

006 

49.404101 242 

006 

46.400320462 

0 

47.399539993 

0 

49  382799903 

0 

49.389978123 

0 

50.385197343 

006 

(161)  Actrvtty  <ltem> 

^ck  Animation  1  Comments 


Process  [  Cost  |  Shuidown  |  Pi^mpt  ]  Reaurts  |  Contents  |  Hem  Animattor)  | 


Processes  orM  or  more  Hems  sknutteneously; 
outputs  each  item  as  soon  as  H  is  firttshed 


OKI 


Cancet 


’Defir>e  capaoty 
Maximum  items  in  acbvity; 


3 


'  Speedy  processing  time  (delay) 

Delay  is;  (speerfied  by  a  distnbubon  J 
Distribution:  [Log norma) 


Delay  (D):  (>6  97425087  ]  time  units 


Mean 

Std  Dev: 


|r 


Plot  Sample 


Location-  ^ 


[~~|lJse  block  seed  [l62 


’  Defirie  other  processing  behavior 
^Simulate  multitasking  activity 
Use  shift  I 


^  □Preempt  when  block  goes  oti  shift 


Block  typo  Residence 
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[161]  Actrvily  <ltem> 


[161]  ActMly  <ltem> 


[161]  Kerns' DistritMition 


PtfCAtn  Itwrs 

Item*'  OistntH/Uon 

521?; 

r 

^  u 

}  7375 

I 

4363 

107 

(161)  Itm 

SOdS  21 47406 

5*  Distribution 

3210724 
nttrairval  Tvnt 

4292044 

53.6 

itefamvsl  Tlmt 

iFK  Nems 

^  -n 

11.638213W6 

006 

12.501976773 

096 

13.37«t9640 

06 

14.2S2MB926 

1  9 

19.127669401 

2 

16.003026279 

34 

16.07«I91194 

3  79 

17.793794031 

52 

16.629116907 

556 

16.004479704 

536 

20.37604266 

03& 

21.290209937 

456 

22.130969413 

096 

23.006031280 

65 

23.601264160 

SS 

24.796697042 

59 

29.632019910 

41 

26.907302799 

4  75 

27.302749672 

4 

26.296106946 

336 

29.133471401 

266 

30.006634301 

306 

30.964197177 

256 

31.796960094 

196 

32  63402290 

1  6 

33  9103Mi0T 

09 

34.360646963 

145 

35  261011906 

096 

36.136374436 

106 

37.011737312 

07 

37.887100160 

055 

36  760403060 

0  45 

39  637820642 

03 

40913166616 

059 

41.368691664 

0 

42.263914571 

01 

43.136S77447 

006 

44  014640304 

006 

44  6600032 

016 

45  706300077 

006 

46  640736363 

019 

47.516091629 

006 

46.301464706 

0 

49  29017662 

006 

90.142180456 

0 

91  017643339 

0 

91.802900212 

0 

92.766269066 

0 

93  943631660 

006 
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[162]  Actrvity  <tteiTi> 


(1<2]  Acttvtiy  <llMn> 


1162]  ActMty  <Kefn> 

|164]  Select  Item  In  <ltetii> 

Options  I  Stock  Animabon  |  Comments  | _ 

Selects  an  input  and  outputs  Its  item  [  ^ 

I  CarKel  I 

rSpecrfy  selection  rule - 

Select  input  based  on;  [merge 


Select  options  and  report  throughput 


QShow  throughput  on  icon 


i-'criiicjck 

th/'Ct.crojt 

0 

r  ■ 

1 

•^^tOreaard;i58( 

»2 

2 

MbiJ Part 

4 

6/ock  type  Dedson 
(164)  Select  Hem  In  <Hem> 


[164]  Select  Hem  In  <Hem> 


rwriitecte 

Tttf(X4jhout 

6 

tT 

1 

>aitGoboard|t5e) 

12 

2 

riMd  Part 

« 
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[184]  Select  Item  In  <ltem> 

Options  I  BloOt  Animation  |  Comments  | 


1  OK  I 

Selects  an  input  and  outputs  its  Hem 

1  Cancel  I 

'Specify  selection  rule 

Seltcl  Input  based  on:  | merge 

“3 

’  Select  options  and  report  throughput 


QShow  throughput  on  icon 


ficrrfiiock  Tr-fougriout 

0 

1  Ke 

1 

2 

t  A  Aatffipt 

Fk*^200 

l 

Block  type  Dodsion 


11841 

Select  Item  In 

<ltem> 

[1841 

Select  Hem  In 

<nem> 

PfOfflSDCil 

Tivoenput 

D 

•  <£A  R».Anwrt|)t 

1 

:S£A  ABtinpt  Rep 

S3 

2 

8|>^V  FttMpOO 

5 

[187]  Activity  <ltenn> 

I  Block  Anenation  |  Comment* 


PrcKess  I  Cost  |  Shutdown  |  Prompt  ]  Results  |  Contents  |  Item  Animation  ~| 


Processes  one  or  more  Hems  simultaneously: 
outputs  each  Hem  as  soon  as  It  is  fvushed 


OK 


Cancel  | 


"Define capecfty  - 

Maximum  items  in  activity  [F 


"Specify  processing  time  (delay)  - 

Delay  IS.  [speoheo  t>y  a  distnouiion  J 
Distribution:  | Normal 


Delay  (D):  |30  &526943r|  Ume  units 


Mean: 
Std  Dev: 


K 


li 


J 


Plot  Sample 


Q  Ose  block  seed  |i88 


‘Defirie  other  processing  behavior  ' 
[^Simulate  multitasking  activity 
Use  shift  I 


"31  Q  Preempt  when  block  goes  off  shift 


Bfock  typo  Residence 


[187]  Activity  <ltem> 


[187]  Activity  <ltem> 
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[189]  Equation  <Vaiue> 

Equation  |  Options  |  Comments  | 


Computes  an  equation  and  outputs  the  resuRs  |  -* 

I  Open  Devetoper  Reference  |  [  Canoe!  } 

"Define  input  and  output  vanables - 

Input  ^nabtes _  Output  Vanables  (results) 


1  VstMUtyp* 

Varvaoe  Nvrr* 

VartaWe  Vaiua  I 

1  I  Conr^ctorO 

,  irConO 

S127 

"  Enter  the  equation  in  the  form  'result  =  formula;* 


outConO  ~  inConO  *  1. 

I  Open  /  Cloee  Equation  Edtor  I 

□Enable  Debugger  |  Set  Breakpointa  1 

1  Test  Equation  1 

QUse  include  files 
[189]  Equation  <Valiie> 


1 

VvwMe  Type 

Vvabte  Name 

Vanabte  Value 

»  1 

CcTfwry  0 

_  rCarO 

812? 

1189] 

A 

1 

«a 

> 

V 

1 

1 

s 

1 

Vwiabla  Typa 

VaroDle  Nwne 

VanaUe  Value 

1  1 

Ccrr<«rw0 

_  ccfCcrO 

8120 

11891 

Equation  <Value> 

[20€]  Select  Item  Out  <Rem> 

Options  I  Item  Ananation  |  Block  Animation  |  Comments  | 


Sends  each  item  to  a  selected  output  ^  * 

i  Cancel  I 


Specify  selection  conditions 

Select  output  based  on  | random  D 

QUse  block  seed  [201  | 

"b 

eiea  options 

If  output  IS  blocked  |  l■.eln  ww  w  •  •  ^ •  r~  ^ 

^Predict  the  path  of  the  item  before  i  enters  this  block 
[I^Show  throughput  on  icon 

To  Bioet  Prebabtlly  Thipughput 

1 

2 

-.-vi:;  095 

ja!'<ect  Hem  Ir<l8q  0  05  5 

iO 

Equal  Probablhbes  1 
^Show  probabilities  on  icon 

Bfock  type  Decision 

(200)  Select  Item  Out  <llem> 


To  Stock 

PMbaMir  ThfoughiHa 

1 

09S  78 

2 

005  5 
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[200]  Select  Item  Out  <Kem> 


Wofkslieet  Dialogs 


[200]  Select  Item  Out  <Mem> 

(211)  Wrlle[l)  <tlem> 

Write  Data  I  Options  J  Item  Animation  |  Block  Anlmabon  ]  Comments  | 


WrKes  data  to  a  database  when  an  Hem  arrives  V  -I 

I  Cancel  I 

"Select  database  and  define  database  coordinates 


Database  Ibatabase  1  ~3  I  Open  selected  database  ]  |  Open  selected  table 


Biock  type.  Passing 

[211]  WritefI)  <ltem> 


VWtie  N*rne 

Tattle 

Reid 

R«co^ 

OBTFR 

/i^Seuree 

Value 

* 

W1 

Output 

«  T«n»ToAep«r« 

ConO  • 

■ 

RV 

2ei  601 7566496 

1225) 

Select  Item  In 

<ltem> 

Options  I  Block  Animation  |  Comments 


Selects  an  input  and  outputs  its  Item  ;  [ 

[Cancel  ] 

"Specify  selection  rule 

Select  input  based  on:  [merge  "J 


’  Select  options  and  report  throuQhput 


QShow  throughput  on  icon 


7T-.'^tiCr«ul 

0 

r «r:isj 

1 

RUCrK(220} 

2272 

2 

•SEA  Fk(2211 

1106 

9 

RYP'mP«f223 

76 

Block  type  Oeoraoo 


[225] 

Select  Item  In 

<ltem> 

12261 

Select  Hem  In 

<llem> 

r<onidtoc1( 

Thm4d  vut 

5 

4670 

1 

RMCF«(220j 

2272 

2 

iSCA  Eb(221] 

1108 

9 

rvawavR<2<b) 

76 
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[231]  Exit  <ltem> 

Report  I  Animation  |  Comments  | 


Passes  items  out  of  the  simulation  ^ 

I  Cancel  | 

'Reports results  - 

Total  eMted 
|B127 


Block  type  Rostdonco 
[231]  Exit  <ltem> 


1  NurrOer  Eitod  Ignore  Rceeto 

i  1  8127  B 

1 

1 

Number  ExMd  Ignore  Reeeab 

’  1 

«t27  B 

[236]  Equation(l)  <ltem> 

Equation  |  Options  |  Item  Animation  |  Block  Animation  |  Comments 


Computes  an  equation  when  an  item  arrives  and  outputs  the  results 
“  Define  Input  and  output  variables - 


Open  Developer  Reference 


[  CanceT" 


Output  Variables  (results) 


1  VenabieType 

VviebieNepre  VeneWe  Value  rtneiMm  uaa 

1  1  Anreuie 

•  Age  »  ?ei  6017598456 

'Enter  the  equation  In  the  form  Vesult «  formula;" 


Age  =  CurrentTime-BirthTIme. 


I  Open  /  Close  Equation  Edilor~|  QEnable  Debugger  [  Set  Breakpoints  |  |  Test  Equation 


□  Use  include  flies 
Block  type 


Passing 

[236]  Equation(l)  <ltem> 


1  Vanable  f  ype 

VanMIa  N«Tia  Vanabla  Value 

*  1  ATtrt»-A* 

^  ftmTfr*  ^53*6600  8710093 

[236]  Equation(l)  <ltem> 


1  Vanable  Type 

Varable  Name  Vanable  Value  S  no  item  use 

*  1  Affrbuie 

^  Age  ^  3616017568456 

[236]  Equatlon(l)  <ltem> 
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[237]  Write(0  <ltefn> 

Write  Data  |  pptKwa  |  Item  Animation  |  Block  Animation  |  Comments  | 


Writes  data  to  a  database  when  an  item  arrives  i. - 1 

I  Cancel  1 

'Select  database  and  define  database  coordeiates - 


Database  | Database  1  J  |  Open  selected  database  1  [  Open  selected  table  ] 


Block  type  Passing 
[237]  Wrlle(l)  <llem> 


f  VWlH  N«m* 

Taoe 

FifU 

R«cord 

OeTSR 

youfoe 

Valu*  Vettan 

1  1  vvl 

Oirtpc* 

,  TfrwToftefMir^ 

CcrO  ^ 

RV 

,45  213033054366 

[238]  E<|uatkm(l)  <ltem> 

Equation  |  Options  |  Item  Animatiofi  |  Block  Animation  |  Comments  | 


Computes  an  equation  when  an  dem  arrives  artd  outputs  the  results  *  * 

I  Open  Developer  Reference  |  |  Cancel  | 

“  Define  input  and  output  variables - 


Input  Wriabtes 


VanabM  tytM  VaroMNaim  VariaMaValu* 

' 

AtnbuM  ,  BiiViTifna  ,  S2SW11  8671^2 

Output  \^riabies  (results) 


1  VanabeType 

VaraoleNanta  Vanable  Value  ttnoitem,  uae 

t  1  ABrbute 

,  Ape  ,45^393305056 

‘  Enter  the  equation  in  the  form  'result  ■  formula;** 
Age  s  CurrentTime-BIrthTlme, 


I  Op«n  /  Clo»  Equation  Edilor  I  □Enable  Debugger  [  Sal  Breakpoints  |  |  Test  Equation  I 


□  Use  include  files 
Bloch  typo 


Pasting 

|238)  EquitKxi(l)  '';ltem> 


[ 

VanableTyve 

Varabte  Nanw  Vartabie  Value 

^  I 

,  BrltiTtne  ,5256611  0671542 
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Wofkstieet  Dialogs 

[238]  Equation(l]  <ltem> 


1  VambleType 

Vanatle  Name  Vanabte  Value  tf  no  riem  uae 

*  I 

^  A9a  ^  42  213B33C:043Se 

[238]  Equatk>n(l]  <lt«m> 


[241]  Write(l)  <ltem> 

Wrile  Data  |  options  |  Hem  Animation  |  Block  Animation  |  Comments  | 


Wries  data  to  a  database  when  an  item  arrives  l— —  J 

I  Cancel  I 

'Select  database  and  define  database  coordeiates  — 


Database  | Database  1  J  I  Open  selected  database  ]  [  Open  selected  table  | 


Block  typo  Possing 
[241]  Wrrte(l)  <llem> 


[  WHaName 

Taoia 

Fiald 

Racon) 

C»TFR 

VMa 

wr«a  Souroa  Vaiua  vwsao 

1  j  V»1 

Outp/ 

9  TmeTof^epair  ^ 

Ccr  0  « 

\  « 

RV 

•  *04  430304122157 
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[242]  Equatjon(l)  <ltem> 

Equatton  |  Options  |  Item  Animation  |  Block  Animatioo  |  Commenta  ~| 

Computes  an  equation  when  an  item  arrives  and  outputs  the  results  _  [  ^ 

[  Open  Developer  Refererxe  ]  [  Cancel  ] 

r  Define  Input  and  output  vanablee - 

inputVanablea _ 

[  I  Vn»b*»Typ»  V«rt>bt»Valu» 

i  I  AtnbuM  ~  BueiTiir#  ^  5J5W13  0MW49 


I 


Output  Vtanables  (results) 


'  Enter  the  equation  in  the  form  “result  ■  formula:** 


Age  =  Current  Time-BirthTIme. 


I  Open  /  Clo»  Equallon  Editor  I  □Enable  Debugger  |  Set  Breakpoints  I  |  Teel  Equation 


□  Use  inctude  files 
Stock  typo. 


Passing 

[242] 

Equation(l)  <ltem> 

VanaUeType 

Vanabla  Name  Vanabte  V^ue 

• 

[242] 

Anrbrj* 

Equation(l)  <ltem> 

^  ennrme  ^  0660940 

VanaUeType 

Vartable  Name  Vanabte  Value  M  no  item  uae 

1 

Attrb<Jle 

V  Age  ^«4  43aM4l22l57 

[242]  Equation(l)  <ltem> 
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[247]  WriteO)  <tlem> 

Write  Data  |  Qpbons  |  Hem  Animation  |  Block  Animatwn  |  Comments  | 


Writes  data  to  a  database  when  an  Hem  arrives  | 

I  Cancel  | 

“Select  database  and  define  database  coordnales - 


Database  | Database  i  J  |  Open  selected  database  |  [  Open  selected  table 


Block  type  Passing 
[247]  Write(l)  <ltem> 


1 

Tabto 

Record 

OSTf  R 

VMe 

Wree  Source 

Value  Wroen 

1  o' 

Output 

^  Tsnelcftepair^ 

ConO  , 

:  21  It 

RV 

- 

,  S27a{»2<SlQ0S3 

[248]  Equation^)  <ltem> 


Equation  |  Options  |  Item  Animation  |  Block  Animation  |  Comments  | 

I  OK  I 

Computes  an  equation  when  an  Item  arrives  and  outputs  the  results  •  * 

I  Open  Developer  Reference  ]  |  Cancel  | 


’  Define  input  and  output  variables 


Input  ^riabtes  Output  \^riables  (results) 


1  VenaM  tfP*  Varottie  Naire  VanaWe  Value 

1  VanatAType  VaroIrleNarw  VenableValue  tf  noitarn,  use 

1  I  AtrOMaCe  «  BiimTiine  « U3C6ae  ISCK’ie 

t  1  Attreuto  ^  Age  ^$27  8032461905$ 

’  Enter  the  equation  in  the  form  'result  ■  formula:” 
Age  B  CurrentTime'BIrthTime. 


I  open  I  Clo»  Equation  Ed«or  I  □Enable  Debugaer  [  Set  B<eakpolnte  I  |  Test  Equation  I 


□  Use  include  files 
Block  typo 


Passing 

|24S|  Equatlon(l)  <lle(T» 


1 

VambieTive 

VinabteNinK  VnsWeVaup 

’  1 

AttnbJle 

,  &f1hTme  ^  5230539  130921  & 
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[248]  Equation(l]  <ltem> 


Wofitslieet  Dtaloos 


1  Variable  Type 

VanableNama  Vanabte  Value  Nnorlem  uie 

’  1  Anrlxfte 

^  Aige  ^  ea32Aty90ti 

[248]  Equation(l]  <ltem> 


[268]  Activity  <lt0m> 

I  Block  Animation  I  Comments  I 


Process  |  Cost  |  ShuKiown  |  Pi^mpt  |  ResUts  |  Corrtents  |  item  Animation  | 


Processes  one  or  more  Nems  simultaneously: 
outputs  each  item  as  soon  as  H  is  hnished 


’Define  capacity 
Maximum  items  in  acbvtty:  [i~ 


3 


okH 


Canc«)  I 


Spettfy  processing  time  (delay)  - 

Delay  is;  [specifted  by  a  distnbution  J 
Oisfribubon:  [Mormal  ~ 


Delay  (D>:  1596  615067^1  time  units 


Mean: 
Std  Dev: 


1500 


Plot  Sample 


Q  Use  block  seed  ^9 


*  Define  other  processing  behavior  ' 
QSimulate  multitasking  activity 
Use  shift.  I 


[^Preempt  when  block  goes  oft  shift 


Biock  type  /Residence 


[268]  Activity  <ttem> 


[268]  Activity  <ttem> 

[284]  Create  <ltem> 

Create  |  Options  |  Item  Animation  |  Block  Animation  |  Comments  |  

(  OK  I 

Creates  items  arKl  values  randomly  or  by  schedule  ^  ' 

I  Cancel  | 

r  Select  block  behavior 

ICreate  items  by  schedule  J  Time  units  generic* 


Block  type  Residence  ‘model  defeult 

[284]  Create  <ltem> 
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Worksheet  Dialogs 

[284]  Create  <ltem> 


1  .  Create  Time  .  Item  Quantity.  Item  Priority  . 

None  . 

None  . 

None  . 

1  1  0  1  1 

[284]  Create  <ltem> 
[284]  Create  <item> 

I  I  0 
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B 


INTEGRATED  DISTANCE  SUPPORT 


t2|  Activity  <A«m> 


320 


WofKslig€t  Dialogs 


(2]  ttems*  Oisiributioo 


p]  Items’  Distribution 


ritaramvai  TinH 

1 1  •  JX 

9M38»in28 

0  76 

14.1140e976e 

265 

10BS464T914 

545 

310IS0NM 

735 

27  4<S60«20e 

97 

31.919992392 

1035 

36  99*490497 

97 

40  919999943 

936 

45  2S7419799 

91 

49  717994936 

95 

94169373091 

55 

99.619901277 

4  15 

93  099329372 

445 

97  919907519 

3 

71.970299664 

20 

76  43076391 

21 

90  971241996 

1  9 

95.321730101 

1  0 

89  772199247 

165 

94  233979399 

1 

99  673194999 

97 

103  12393299 

06 

107  87411093 

09 

112  09499999 

07 

116  47906712 

015 

120  93864927 

0  45 

125  37902341 

015 

129  93990199 

025 

134  27997971 

005 

136  72745796 

015 

143177939 

005 

147  62941414 

006 

152  07899229 

005 

156  92937043 

015 

160  97994899 

01 

169  43092979 

0 

169  99090497 

005 

174  33129392 

005 

171  79179119 

0 

193  23223331 

0 

197  99271749 

0 

192  1331999 

005 

199  59397375 

0 

201.03415199 

0 

205  49463004 

0 

209  M510919 

0 

21439559933 

005 

213  93605449 

0 

223.29654292 

0 

227  73702077 

005 
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[4]  Select  Item  Out  <ltem> 

Options  I  Hem  Animation  |  BtocK  Animation  |  Commenie  | 


Sends  each  item  to  a  selected  output  ^ 

I  Cancel  | 

"Specify  selection  conditions - 

Select  output  based  on;  | random  J 

□Use  Wock  seed  (s  | 


Select  options 


If  output  IS  blocked:  litem  win  was  for  blocked  output  J 
□  Predict  the  path  of  the  item  before  it  enters  this  block 
□Show  throughput  on  icon 


ToBtou  ProboMiv  ThroMonput 

t 

2 

Se‘ect  liem  m(i01  02  ■ 

50 

-J 

Equal  Probabilibes  | 


□  Show  probabilities  on  icon 


Block  type  Decision 


[41 

Select  Item  Out 

<ltem> 

— 

I  Toeiocii 

1  PjrtOnioSdiSf 

nntabiir 

08 

riifOkMtiput 

n 

2 

ISeiKt  ln(tCI) 

02 

r 

i«i 

Select  Item  Out 

<ltem> 

14) 

Select  Item  Out 

<ltetn> 

Id 

Select  Hem  Out 

Options  I  Item  Ansnation  |  Block  Animation  |  Comments  ] 


Sends  each  item  to  a  selected  output  ^  '  * 

ICafioei  I 

‘Specify  selection  conditions - 

Select  output  based  on:  |faf>dom  J 

□Use  btock  seed  |6  ~1 

'Select  options - 

If  output  IS  blocked  [item  wW  was  far  blocked  output  J 
□  Predict  the  path  of  the  item  before  A  enters  this  btock 


□  Show  probabilities  on  icon 


Block  type  Decision 

[5]  Select  Item  Out  <ltem> 


[  To  Block 

rmhawtii 

TtiraugtipiS 

1 

|tt£A  0T4e»  or  Sa 

06 

ejPW 

2 

ISdect  Itom  in(lQ) 

02 

TSSO 

Id 

Select  Item  Out 

<ltein> 

(6]  Select  Item  Out  <ltem> 
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[6]  Actrvfty  <tterrp 


I  Block  Animation  |  Comments  | 


Process  I  Cost  |  ShuiOown  |  Preempt  ]  Results  |  Contents  |  ttem  Animattor^  ] 


Processes  one  or  more  Hems  simultaneously; 
outputs  each  item  as  soon  as  it  is  finished 


OK 


‘C>ef)r>e  capaccty 
Maximum  items  in  actrvity  ^ 


'Specify  processing  time  (delay) 


Delay  is-  jspecifieo  by  a  distnthjtiofrj  Delay  (0):  pS  0663972^1  time  units 


Dtstributoon:  [Lognormal 

Mean.  [i2 
Std  Dev: 


Plot  Sample 


Location:  [cT 


[~|Use  block  seed  ^ 


'Define  other  processing  behavior  ' 
□Simulate  multitasking  activity 
Use  shift  I 


□  Preempt  when  block  goes  off  shift 


Bfock  type  Residence 


[f]  ActMty  <Kein> 


(6]  Activity  <nem> 


-■PMe-S 
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Worksheet  DUIoqs 


InMTMTTvai  Ttm* 


6.oeeei42oe7 

085 

662S61S49S7 

13 

a.iro62«6e28 

295 

s.riis29se8e 

35 

11.2S2S)9117 

495 

12.7936*0344 

95 

14.334649971 

9  75 

19.979660796 

SS 

17.416696029 

99 

16.967661292 

905 

M.49tte*4r* 

«.15 

22.033671706 

95 

23  960676933 

525 

29.12168216 

44 

26.683967366 

43 

28.203682619 

23 

29.744637942 

31 

31.296703098 

4 

32.626709299 

24 

34.367713923 

245 

38.90671679 

2  15 

37449723977 

1  3 

39.960729204 

1  56 

40  931734431 

1  4 

42.072739696 

07 

43  613744989 

145 

49194790112 

106 

46.696799338 

0  25 

49  236760996 

096 

49  777769793 

03 

91.31677102 

0  45 

92.996776249 

03 

94.400761479 

04 

99.941766702 

03 

97.462731929 

03 

99  023787186 

015 

60.864802393 

025 

62.10960791 

01 

63.646612937 

02 

69.197919064 

005 

66.729923231 

0.2 

66.263626816 

01 

69.910633749 

Of 

71.391639972 

005 

72.8826*4196 

015 

74,4336*9426 

01 

79.974694693 

0 

77  91869966 

0 

79.096869106 

005 

60.997670339 

006 

Activity 

<ltem> 

Process  [  Cost  |  Shutdown  |  Pi^mpt  ]  Reaurts  |  Contents  |  Hem  Animatior)  | 


Processes  orM  or  more  Hems  senutteneously; 
outputs  each  item  as  soon  as  H  is  firtished 


OKI 


Cancet 


’Defir>e  capaoty 
Maximum  items  in  acbvity; 


3 


'  Speedy  processing  time  (delay) 

Delay  is;  (speofied  by  a  distnbubon  J 
Distribution:  [Lognormai 


Delay  (0):  [44  54824435 1  time  units 


Mean 

Std  Dev: 


48 


12 


Plot  Sample 


Location-  ^ 


(~|  Lise  block  seed  ^ 


’  Defirie  other  processing  behavior 
^Simulate  multitasking  activity 
Use  shift  I 


^  □Preempt  when  block  goes  oti  shift 


Block  typo  Residence 
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(7]  Acth/ity  <Nefn> 


(7]  Activity  <nefn> 


[7]  Hems'  Distribution 


F*tfc*ntn*n« 

Itemi  Disf.  Cc!  o 

5  2125 

• 

.K- 

1  7375 

_r 

9641 

23.2 

[7]  Hems' 

3132 

)istrtt>ulion 

6270202 

1021227 
ntaramvai  I'm* 

141.5434 

160 

TO 

264S69406M 

ots 

26.ri7396M7 

1 

32  936373127 

1  36 

9B1&33e934« 

1  0 

39.371403966 

22 

42  9«942ir»4 

356 

49I07436003 

42 

49.026464223 

346 

62.243470M1 

656 

3046148666 

545 

9«<79e<l2879 

096 

61.M79190M 

566 

69.118636310 

02 

60.333661937 

556 

71.961967790 

49 

74  700003078 

46 

n.oersoom 

46 

01.209616413 

46 

04  423632632 

41 

67.641640661 

37 

90.06066907 

296 

94  07760129 

23 

97.200007000 

256 

100.91371373 

1  9 

103  73172906 

22 

100  94074017 

1  25 

11010776239 

1 

1133967706 

096 

11660379402 

075 

119.62181104 

086 

123  03002720 

07 

120  20784340 

06 

1294708007 

03 

132  60387992 

03 

138  91189214 

03 

139.12980636 

03 

142  34703400 

025 

1466000400 

006 

148  78399701 

02 

152  00197323 

02 

199  21999940 

01 

199  43000067 

006 

161  60602199 

025 

164  97403811 

006 

108  00209433 

0 

171  31007066 

0 

174  92008677 

0 

177.74010296 

0 

180  98(11921 

006 
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|8|  Activity  <Hem> 

I  Btock  Animation  |  Comments  | 


Process  |  Cost  [  ^uttfown  |  Preempt  |  Re&utts  |  Contents  |  ttem  Antmatwn  | 


Processes  one  or  more  items  simultaneousiy; 
outputs  each  item  as  soon  as  it  is  finished 


OK 


~[>efir>e  capacity 
Maximum  items  in  activity  |i~ 


Specify  processing  time  (delay) - 

Delay  is*  Ispecified  by  a  diatnbutior>  J 
Distribution;  jfkirmar  ~ 


Delay  (0):  js  2545522 1  FI  t>m e  units 


Mean: 
Std  Dev: 


12 


Plot  Sample 


Q  Use  blocSi  seed  ^ 


[•I  ActMty  <ftam> 


[8]  Activity  <ltem> 

[9]  Select  Item  Out  <llem> 

Options  I  Item  Anmaton  |  Stock  Animation  |  Comments  | _ 

Sends  each  Mem  to  a  selected  output  |  | 

I  Cancel  I 

r  Specify  selection  conditions - 

Select  output  based  on:  [random  J 

Q Use  Mock  seed  |i0  ~| 

r  Select  options - 

Ifouiput  IS  blocked  [item  writ  waa  to  Mocked  output 
Q  Predict  the  path  of  the  item  before  M  enters  this  block 
QShow  throughput  on  icon 


PrabaMty 

Tnreughput 

1 

0  9  •••:' 

2 

.  Re  Aitcmpi  fte  01 

1016 

TO-) 

Equal  Probabilities  1 


QShow  probabilities  on  icon 


8/oc/r  type  Decision 


[9]  Select  item  Out 

<ltem> 

[  Tefileck 

PMum, 

Throughput 

'  1 

09 

2  p'i 

01 

1016 

[9]  Select  Item  Out 

<Item> 
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[9]  Select  Item  Out  <nem> 

[10]  Select  Hem  In  <ltem> 

Options  I  Block  Animation  |  Comments  | _ 


1  OK  1 

Selects  an  Input  and  outputs  Its  Hem 

1  Cancel  I 

’Specify  selection  rule 

Select  input  based  on:  |rT>erge 

Z33 

’Select  options  end  report  throughput 


QShow  throughput  on  icon 


Ffo«~feioci>  Thfo<jcnairt 

0 

t 

2 

Part  Or*oard|9|  ilrric 

DSNeMPwt|4} 

EL 

l 

Stock  type  Dedston 


110) 

Select  Hem  In 

<ltefn> 

[101 

Select  Hem  In 

<ttem> 

Fiorr^kjck 

TtvOLUVUt 

0 

Par*/] 

6393 

1 

Part  Oneoard|S| 

iseo 

2 

DSNee4<Vl{4] 

1963 

[37]  Select  Hem  Out  <ltem> 


Options  I  hem  Animation  j  Biock  Animatior\  j  Comments  | 


Sends  each  Item  to  a  selected  output  ^  —  * 

I  Cancel  1 


‘Specify  selection  conditions 
Select  output  based  on'  [rarxlom  J 

□Use  tsiock  seed:  |38  ] 

’Select  options - 

IfOUtpUtlSbIOCked.  Iron,  wm  ««ii  Kt  .  >  '  t'.  _ 

□  Predict  the  path  of  the  item  before  it  enters  this  block 


□Show  probabilities  on  icon 


Stock  type  Oecisron 
[37]  Select  Hem  Out  <Hem> 


[37] 


let?  Ir*;i84’ 

seectlt*m'< 
Select  Hem  Out 


FiolwMSy  Throuonpm 

01 

09  mr 

<ltem> 


P7]  Select  Hem  Out  <ltem> 
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[40]  Select  Item  In  <ltem> 

Options  I  Block  Animation  |  Comments  | 


1  OK  1 

Selects  an  input  and  outputs  its  item 

[  Cancel  I 

'Specify  selection  rule 

S*l«cl  Input  bsMd  on:  |  merge 

Select  options  and  report  throughput 


QShow  throughput  on  icon 


FfonViixark  rr'<obgfx>iit 

0 

1 

3 

S  R«  TfC.' 

J 

Biock  (ype  Oecreon 
{40)  Select  Item  In  <ltem> 


[40]  Select  Item  In  <ltem> 

'teai  PTOM»<r|6^  i 

1  Pi*Q6(«ntS7l  MXa 

7  ra  fUAa^nmt  r*  gor 

(57)  Create  <item> 

Create  {  Options  |  ttem  Animation  |  Block  Animation  |  Comments  [ 


Creates  items  ar»d  va  lues  randomly  or  by  schedule  | 

[  Cancel) 

'Select  block  behavior - 

ifcreate  <ems  by  schedule  J  Time  units  gerienc* 


Enter  a  schedule  of  arnvai  times 


Q  Repeat  the  schedule  every 
Total  cost:  |q  ] 


Btock  type  Reardence  ^model  default 

[57]  Create  <ltem> 


[57]  Create  <ltem> 


1  .CteateTime  .  itein  Ouanlitir*   llem  Primly  .. 

None  » 

Norw  « 

None  M 

1 

5“^  1  1 

1671 

Create  <ltem> 

1*7) 

Create  <ltem> 

I ! » 
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Woffcsheot  Dtalocis 


(57]  Items’ Distribution 


(67)  Items*  Distribution 


Intafamval  Tim« 

■am* 

149  SXMm 

006 

193  36479834 

0 

17740494S4 

01 

191  49610046 

035 

309S063616 

01 

319  96640296 

005 

2338099S3S 

015 

347  88670464 

035 

261  70608986 

0  49 

37S  76600674 

04 

289  80819779 

105 

303.86630864 

095 

317  90845988 

1  3 

331  96861089 

1  4 

349  00676198 

3  49 

380  06891301 

1  45 

374.10706408 

345 

388  16721912 

36 

403  30738617 

315 

4t<2S781732 

32S 

430  30780037 

46 

444  36781933 

49 

498  40797038 

96 

47249813141 

636 

486  90827348 

44 

500  59642361 

635 

914  60067498 

556 

9386887388 

555 

542  70887688 

45 

998  7980277 

406 

570  80917976 

435 

964  8693398 

3  75 

998  90648064 

33 

61396983189 

39 

637  00978294 

34 

641  06993396 

236 

835.11008964 

t  9 

669  18023906 

1  35 

683  31038713 

1 

897  38053878 

05 

711  31088923 

07 

739  38084038 

085 

739.41069133 

035 

753  46114337 

0.2 

767  91129343 

0.1 

781  58144447 

015 

TMSrtSMS} 

0 

809  88174657 

005 

823.71189781 

005 

837  78304988 

005 

(51]  Exit  <ttem> 

Report  I  Animation  ]  Comments  | 


Passes  items  out  of  the  simulation  * 

1  Car>ce<  | 

‘Reports  results - 
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{61]  Exit  <Kem> 

IN  umber  Ex  Bed  ignof  Ra>o 
904®“^  B 


[156]  Activity  <ltem> 

Stock  Animatior)  |  Comments 


Process  [  Cost  |  Shutdown  |  Preempt  |  Results  |  Contents  |  item  Animation  | 


Processes  one  or  more  Nems  simultaneously: 
outputs  each  ttem  as  soon  as  it  is  fvHshed 


'Defirve  capacity 
Manmum  items  in  activity  R~ 


3 


OK 


Cancel 


‘SpectIV  processing  time  (delay) 

Delay  is’  {speci5ed  by  a  distributon  J 
Distribution:  iNofmai  ~ 


Mean 
Std  Dev- 


|r 


Delay  (D):  {23  &1 921 504  |  time  units 


[  Plot  Sample 


f~~lUse  block  seed  [l57 


“Define  Other  processing  behavior 
^Simulate  muttrtaskvig  activity 
Use  shill  I 


QPreempl  when  block  goes  oft  shift 


Block  type  Residence 


{156]  Activity  <ltefn> 


{166]  Activity  <ltem> 

[158]  Select  Item  Out  <Rem> 

Options  I  Item  Animation  |  Stock  Animation  |  Comments  [ _ 

I  OK  I 

Sends  each  item  to  a  selected  output  ' - ' 

I  Cancel  I 

r  Specify  selection  conditions  ■■■  -■  — . — ■ 

Select  output  based  on'  {random  J 

□  Use  block  seed:  |159  | 

r  Select  options - 

If  output  is  btocked  ww  rwmm  ■  1^  TT;  . ^ 


□Predict  the  path  of  the  item  before  it  enters  this  block 
□Show  throughput  on  con 


To  8io»  PioboWlir  ThioualiDut 

1 

2 

50 

Oe  100 

>«ctr«mlri(1S4]  01  15 

l^quar  l^fobatiiifes  H 


□Show  probabilities  on  icon 


Block  type  Deds/on 
[168]  Select  Item  Out  <Nem> 

_ ToBlotk _ Piqbahlty _ Thtoxghpul 

1  “'art  CriwatcJ  09  i3J 

2  01  15 
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[158]  Select  Item  Out  <Hem> 


Wofitsheel  Dtaloos 


[158]  Select  Item  Out  <ltem> 

[159]  Select  Item  Out  <Kem> 


Options  I  Item  Animation  |  Blodt  Animation  |  Comments 

Sends  eech  Rem  to  a  selected  output 


I  OK 

[  Cancel 


r  Specify  selection  conditions  ' 


Select  output  based  on  [far>dom 
□Use  block  seed  [160 


‘Select  options  ' 


Ifoutput  is  Plowed'  ingm  ww  wae  <  cut£^ 

□  Predict  tbe  patb  of  die  Item  before  R  enters  this  block 

□  Show  tnroughpot  on  icon 


To  Oioe*  ProboWty  Throughpyl 

1 

-  1-  01  •  0  8 

3 

-  t  n#m(r<194|  0  3  i'" 

ilD 

Equal  Probabilibes  I 

□  Show  probabilities  on  icon 


Biock  type  Decision 


[169)  Select  Item  Out  <Rem> 


•i. ( 

To  Block 

ThmugKput 

’  1 

t.CA  OtO0»  or  • 

08 

2  \ 

Horn  Irtt64t 

02 

18 

[159]  Select  Item  Out  <Rem> 


[159]  Select  Item  Out  <Rem> 
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Worksheet  DUIoqs 


(160)  Actrvity  <tteiTi> 


I  Block  Animation  |  Comments  | 


Process  [  Cost  |  ShuiOown  |  Preempt  ]  Results  |  Contents  |  ttem  Animattor^  ] 


Processes  one  or  more  Hems  simultaneously; 
outputs  each  item  as  soon  as  it  is  finished 


OK 


‘C>ef)r>e  capaccty 
Maximum  items  in  actrvity  ^ 


'Specify  processing  time  (delay) 


Delay  is-  jspecifieo  by  a  distnthjtiofrj  Delay  (0):  3t9709taT|l»me  units 


Dtstributoon:  [Lognormal 

Mean.  [i2 
Std  Dev: 


Plot  Sample 


Location:  [cT 


[~|Use  block  seed  |i61 


'Define  other  processing  behavior  ' 
□Simulate  muttrtaskmg  activity 
Use  shift  I 


□  Preempt  when  block  goes  off  shift 


Block  type  Residence 


(ISO)  Activity  <llam> 


[ISO]  ActMly  <ltefn> 
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[iwj  nems  uistriouuon 


Worksheet  Dialogs 


Intvramval  Titni 

iFTi 

1.Sn>4SS5S19 

OIS 

29«Se74Tr21 

056 

39628939924 

196 

49S»113212S 

406 

9995SS2432S 

5  75 

6.9819016831 

64 

7,94moeT33 

91 

69436900939 

03 

9  9402093130 

81 

10.936129934 

84 

11.932(67784 

58& 

i2.62Meer4 

536 

13.929066199 

51 

14.921309419 

39 

19917924639 

386 

16.913743899 

406 

17.90eeSM7S 

12 

ia.90eit2296 

1  76 

19.902401916 

2 

20.496620736 

1  45 

21.4S«39967 

096 

22.491099177 

t.6 

23.467276367 

065 

24.493497617 

0  76 

29.4r97i6sae 

086 

26.479936066 

055 

27.472196278 

036 

2i.4663744ae 

045 

29.464e8371S 

025 

30460612666 

096 

31.497032196 

026 

32.493291376 

015 

33.449470996 

006 

34.44966962 

006 

39  44190904 

01 

36  43612926 

01 

37.43434746 

01 

36.430966701 

015 

39.426763921 

01 

40.423009141 

006 

41.419224361 

006 

42.419443961 

0 

43.411662602 

0 

44.407862022 

006 

69.404101242 

006 

46.400320462 

0 

47.308639683 

0 

48.382768608 

0 

49.306876126 

0 

60.366167343 

006 

(1611  Activity  <nem> 

I  Stock  Arrimabon  1  Comments 


Process  |  Cost  [  Shutdown  [  Preempt  |  Resutts  |  Contents  |  Rem  Animation  | 


Processes  one  or  more  ttems  senulteneousty; 
outputs  each  item  as  soon  as  it  is  finished 


OK 


Car>cei 


'Define  capacity 
Maximum  items  in  activity:  |i~ 


3 


‘Specify  procesaog  time  (delay) 

Delay  is  Ispecifted  by  a  dlstiitxitioo  J 
Distribution:  iLognormai  ~ 


Delay  (D):  [20  7953955T1  time  unite 


Mean' 
Ski  Devr 


ET 


Plot  Sample 


Location  |d~ 


Q  Use  blodk  seed  [l62 


'Define  other  processing  behavior 
Q  Simulate  multitasking  activity 
Use  shift  I 


^  □Preempt  when  block  goes  off  shift 


Block  typo  Residence 
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Wofltsheel  Dtaloos 


[161]  Activity  <Hefn> 


[161]  Activity  <rtem> 


[161]  Items*  Distribution 


62129 

J"' 

1  737S 

10  75095  21.47406  3219724  42  02044  5364363 

(fltsratTMai  Tvn* 


p61]  Items*  Distribution 

Interamval  T(m4 

1  rix  Neins 

“  SI 

11.62618896 

006 

12.8018767T2 

066 

18.876680646 

06 

14.262808820 

t  6 

19.127669401 

2 

16.008026276 

34 

16.876891194 

375 

17.798794031 

52 

18.620116807 

556 

19.904479784 

936 

20  87604266 

636 

21.296(209987 

456 

22.184660418 

006 

28.0060812M 

09 

28.001204166 

55 

84.796867042 

50 

29.683010016 

41 

26.907862766 

4  75 

27.802746672 

4 

26.296106646 

336 

29.188471424 

206 

80.006684301 

300 

80.064197177 

256 

81.796060064 

1  86 

82  63402308 

16 

88  910200107 

00 

84.300640608 

1  49 

85  261011960 

096 

86  186874480 

1  06 

37.011787312 

07 

87  807100100 

056 

88.7624^088 

0  46 

89  687626042 

08 

40  918100010 

066 

41.380661604 

0 

42.2e36149ri 

01 

48  136877447 

006 

44  014640884 

006 

44M00082 

016 

45  768866077 

006 

46  640730988 

016 

47.616091830 

006 

40.301464700 

0 

49  208017802 

006 

00.142100480 

0 

91  017948836 

0 

91.802006212 

0 

92.766260086 

0 

98  648681866 

006 
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Worksheet  DUIoqs 


[162]  Actrvity  <tteiTi> 


(1<2]  Acttvtiy  <llMn> 


1162]  ActMty  <Kefn> 

|164]  Select  Item  In  <ltetii> 

Options  I  Stock  Animabon  |  Comments  | _ 

Selects  an  input  and  outputs  Its  item  [  ^ 

I  CarKel  I 

rSpecrfy  selection  rule - 

Select  input  based  on;  [merge 


Select  options  and  report  throughput 


QShow  throughput  on  icon 


i-'criiicjck  t 

r-.cugnojt 

0 

1 

•^^tOreaard;i58( 

ts 

2 

MbiJ Part 

t6 

6/ock  type  Dedson 


1164) 

Select  Hem  In 

[164] 

Select  Hem  In 

<Hem> 

rwriitecte 

TtvcxeTeut 

h 

82 

1 

»artGoboard|t5e) 

18 

2 

-Usavwv  NMd  Part 

IS 
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Worksheet  Dialogs 


[184]  Select  llefT)  In  <ltem> 

Options  I  Block  Ammalton  |  Commenta  | 


Selects  an  input  and  outputs  its  item  i - J 

I  Cancel  \ 

'Specify  selection  rule  - 

Select  input  based  on:  | merge  3 


Select  options  and  report  throughput 


QShow  throughput  on  icon 


Frnrf^Jctk  ihiobgriaiil 

0 

t 

rS  H«f  /•JTO-'>'flt  F><>  ' 

FikMPOOI 

l 

Block  typo  Decision 


[1841 

Select  Item  In 

<ltem> 

1184] 

Select  Hern  In 

<ltem> 

F«0(reiock 

TTvoi^neut 

4 

DS  Ff  Att>4n»t  R« 

tos 

Ftttdpoq 

7 

[187]  Activity  <ltem> 


(187]  Activity  <ltem> 


[187]  Activity  <ttem> 
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Worksheet  Dialogs 


[189]  Equation  <Vaiue> 

Equation  |  Options  |  Comments  | 


Computes  an  equation  and  outputs  the  resuRs  |  -* 

I  Open  Devetoper  Reference  |  [  Canoe!  } 

"Define  input  and  output  vanables - 

Input  ^nabtes _  Output  Vanables  (results) 


1  VstMUtyp* 

Varvaoe  Nvrr* 

VariftMoVaiu*  1 

1  I  Conr^ctorO 

,  irConO 

0D4a 

"  Enter  the  equation  in  the  form  'result  =  formula;* 
outConO  ~  inConO  *  1. 


I  Open  /  Close  Equation  EdSor  ] 


□Er\able  Debugger  |  Set  Breakpoints 


1  Test  Equation  | 


QUse  include  files 
[189]  Equation  <Valiie> 


1 

VvwMe  Type 

Vvabte  Name 

Vanabte  Value 

»  1 

CcTfwry  0 

_  rCarO 

S04e 

1189] 

A 

1 

> 

V 

1 

1 

s 

1 

VwtttM  Type 

Varobie  NaiTie 

Vanabla  Value 

1  1 

Ccrr<«rw0 

_  ccfCcrO 

e04& 

11891 

Equation  <Valu«> 

[20€]  Select  Item  Out  <Rem> 

Options  I  Item  Ananation  |  Block  Animation  |  Comments  | 


Sends  each  item  to  a  selected  output  ^  * 

i  Cancel  I 


Specify  selection  conditions 

Select  output  based  on  | random  D 

QUse  block  seed  [201  | 

"b 

eiea  options 

If  output  IS  blocked  |  l■.eln  ww  w  •  ■  ■ - 1 .  •  ^  ^ 

^Predict  the  path  of  the  item  before  i  enters  this  block 
[I^Show  throughput  on  icon 

To  Bioet  Prebabtlly  Thtputftput 

1 

2 

-.-vi:;  095 

ja!'<ect  Hem  Ir<l8q  0  05  7 

in 

Equal  Probablhbes  1 
^Show  probabilities  on  icon 

Bfock  type  Decision 

(200)  Select  Item  Out  <llem> 


Teatock 

PMbeMiar  Thfoughput 

1 

095  109 

2 

ttem  Irtie4l 

005  7 
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(200]  Select  Hem  Out  <lten>> 


Worksheet  Dtalcxis 


(200)  Select  Item  Out  <llefn> 


[60]  Select  Item  m  <ltem> 


Options  I  Block  Animation  Comments 


Selects  an  Input  ar>d  outputs  its  item 

l  OK  1 

1  Canctl  1 

"Specify  selection  rule 

Select  input  based  on:  (merge 

ZZ3 

“Select  optwns  and  report  throuphput 


QShow  throughput  on  icon 


r 

Frerrfireck  Tlwomhoyt 

D«F{ar5e|  SMI 

Rva«»r  r^n{S2)  IOC 

a _ 

Block  type  Decision 

[60]  Select  Item  In  <Keni> 

(60]  Select  Item  In  <ttem> 

FwoiBecte _ ThfW^heMl 

0  I  DSfafSaj  SMI 

1  toe 


(237]  Wrile(I)  <ltem> 

Write  Data  |  Options  |  Item  Animation  ]  Block  Animation  |  Comments  ] 


Writes  data  to  a  database  when  an  Item  arrives  ^  ‘  '• 

I  Cancel  1 

"Select  database  and  define  database  coordnates - 


Database'  fOatabase  t  J  |  Open  selected  database  |  [  Open  selected  table  ] 


Block  type.  Passing 
[237]  Wrtte(l)  <llem> 


Write  liame 

Tteito 

FiHd 

Recwl 

DBTFR 

Whte 

iMrte  Source  VliKie  iMtten 

wt 

uutpu 

^  TfTwToA«p«<r^ 

Cgt-O  ^ 

RV 

^  ^  92  75 1067756875 
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Worksheet  Dialogs 


[238]  Equation(l)  <ltem> 

Equahon  |  Options  |  Hem  Animation  ]  Block  Animation  |  Comments  | 


Computes  an  equation  when  an  item  arrives  and  outputs  the  results 


OK 


Open  Developer  Refererrce  ]  |  Cancel 


‘  Define  input  and  output  vanables 
Input  Virtables 


v«ebi»N<m»  Variabf  Value 


&r9iTifn»  _  $250348  57C061 5 


Output  Vlanabies  (results) 


‘  Enter  the  equation  in  the  form  "result  ■  formula;" 


Age  >  Current  Time-Birthlime. 


I  Open  <  Close  Equation  Ed«or  I  □  Enable  Debugger  |  Set  Breakpoints  I  I  Teel  Equalion  I 


□  Use  include  files 
Block  typo 


Passing 

[238]  Equation(l)  <ltem> 


1  VwwbleTMW 

Varatile  Name 

Vanabte  Value 

1  1  Atinbue 

V  dnhTim  ^ 

laioieTr^tS 

[238]  Equation(l)  <ltem> 

1  Vai«bleType 

Vsneble  Name 

Vanabte  Value  Nno«lem  uee 

•  1 

•  » 

92  761«77S«75 

[238]  Equatior>(l)  <ltem> 
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Worttsheet  Dialogs 


[247]  Write(0  <ltefn> 

Write  Data  |  pptKwa  |  Item  Animation  |  Block  Animation  |  Comments  | 


Writes  data  to  a  database  when  an  item  arrives  i. - 1 

I  Cancel  1 

'Select  database  and  define  database  coordeiates - 


Database  | Database  1  J  |  Open  selected  database  1  [  Open  selected  table  ] 


Block  type  Passing 
[247]  Wrlle(l)  <llem> 


f  VWlH  N«m* 

Taoe 

FifU 

R«cord 

OeTSR 

'/I'rta  youfoe 

Vaki*  Vetton 

1  1  vvl 

Oirtpc* 

,  TfrwToftefMir^ 

CcrO  ^ 

RV 

^  18619760546627 

[243]  E<|uatkm(l)  <ltem> 

Equation  |  Options  |  Item  Animatiofi  |  Block  Animation  |  Comments  | 


Computes  an  equation  when  an  dem  arrives  artd  outputs  the  results  *  * 

I  Open  Developer  Reference  |  |  Cancel  | 

“  Define  input  and  output  variables - 


Input  Wriabtes 


VanabM  r^  VaroMNaim  VariaMaValu* 

' 

AtnbuM  9  BitTiTifn*  « 5177790  7011033 

Output  \^riabies  (results) 


1  VanabeType 

Varaote  Nante 

VanaWa  Value  It  no  item,  uae 

1  1  ABrbute 

^  w 

168  16760240527 

‘  Enter  the  equation  in  the  form  'result  ■  formula;** 
Age  s  CurrentTime-BIrthTlme, 


I  Op«n  /  Clo»  Equation  Edilor  I  □Enable  Debugger  [  Sal  Breakpoints  |  |  Test  Equation  I 


□  Use  include  files 
Bloch  typo 


Pasting 

|248)  EquitKxi(l)  '';ltem> 


I  VanableType 

Varabte  Name  Vartabie  Value 

1  j  *t1rt7Jlp 

^  &rtnTr»  ^5177750  2011036 
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Worksheet  Dialoos 

[24S]  Equatiofi(0  <ltem> 


1  Variable  Type 

Variable  Name  Vanable  Value  Mnoitemuae 

1  1  AtiftbaM 

^  A9e  ^  IBS  18790249^2 r 

[248]  Equatk)n(l]  <ltem> 


[63]  Activity  <lteni> 

[  Block  Animation  |  Comments"] 

Process  I  Cost  |  Shutdown  |  Pi^mpt  |  ResUts  |  Contents  |  Bern  Animatio^ _ 

Processes  one  or  more  Hems  simultaneously;  [_  QK_  _] 

outputs  each  item  as  soon  as  it  is  finished  [  Cancei ") 


Define  capacity 
Maximum  Items  in  activity:  jT 


3 


Specffy  processing  time  (delay) 


Delayis  [spectfied  by  a  distribution  J  Delay  (D):  ^118.204248  |  time  unite 
Otstribubon:  [Normal  J 


Mean:  ^ 

Sid  Dev:  |ioo 


I  Plot  Sample  ] 


□  Use  block  seed  |54 

r  Defirve  other  processing  behavior - 

^Simulate  multitasking  activity 

Use  shill  I  j  □Preempt  when  block  goes  off  shill 

Block  type  Residence 
[63]  Activity  <ltem> 


[63]  Activity  <ltem> 

[68]  Create  <Mem> 

Create  [  Options  |  Hem  Animation  |  Block  Animation  |  Comments  J _ 

I  OK  I 

Creates  Kerns  and  values  randomly  or  by  schedule  ;  ' 

I  Cancel  I 

r  Select  block  behavior 

ICreate  items  by  schedule  J  Time  units  generic* 


Block  type  Residence  ‘mode/  defeuU 

[68]  Create  <ltem> 
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Worksheet  Dialogs 

[68]  Create  <ltem> 


I  Create  Time  ttem  Quantity^  Item  Prjority » 

None  « 

None  » 

None  • 

1  I  0  1  1 

[68]  Create  <ltem> 
[68]  Create  <ltem> 

I  I  2 
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c 


NO  DISTANCE  SUPPORT 


WwfcVwl  Dwioqs 

(0)  Executive  <llem> 

Control  I  mmAttnbutee  |  tiem  Conte nl>  |  0»*Cfete  Rale  f  Bow  At^bulee  j  LP  Sotvtf  |  Commented 

Controls  arKi  does  event  scheduling  for  (  i 

discrete  event  erKf  discrete  rate  models  [  Cancet  1 

r  Select  options - 

Stop  Simulation 

Q  Report  system  events  on  event  conrtector 


’Declare  item  ilocatioo 
Inttallyallocale  |12000  [items 
Allocate  adc4onal  dams  in  batches  of  |1QQ0 


hifOOO  1(0  687  MB) 

P - 1 

F - 1 

*  In  add/6on  lo  user  def/red  aOnPutes.  ffre  system  assigns  1  artnPufe  hranimaton  plus  2  more  H 
cosang  is  used 

(1)  Create  <lterTt> 

Create  |  Options  |  Item  Animation  j  Block  Animation  )  Comments  | _ 


Creates  iems  and  values  randomly  or  by  schedule  ’  ^ 

-SeleUUockbenavw  - 

^  ■  ~~  I _  j  Time  units  generic* 


Bl^k  typa  Residence  ’mode/ dei^ud 

|1]  Create  <Ntfn> 


{1)  Create  <lt»m> 


'Report  system-calculated  resuts  — 
Number  of  cam  rows  aOocaled 
Number  of  atinbutes  lor  each  item* 
Number  of  nam  rows  used 


I  _c«aiHtMna  _iii«n<^ataHy»  _awwPnoie»^  Mow  ^ _ Wore  »  Naif 

V  1  T'"  i““  t 

{1|  Create  <NMn> 


|1]  Create  <ltem> 


I  1 » 
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Wofitsheel  Dialogs 


(1)  ttems*  Distribution 


IntMmval  Timt 

NBms 

149  XM447S1 

008 

163  3ft«7Se36 

0 

1T740694M 

01 

161  4«S10(MS 

038 

M69092S1S 

01 

31699660268 

008 

233  8089818 

018 

347  66870484 

028 

261  70888868 

0  48 

279  79800674 

04 

286  80619779 

1  06 

303 

098 

317  60869888 

1  3 

331  90881068 

1  4 

346  00876168 

245 

360  09861308 

1  4$ 

374  10708408 

2  48 

38818721612 

20 

402  20738817 

318 

416  28781723 

328 

430  30786827 

46 

444  9S7919» 

48 

49840797038 

56 

472  46812141 

638 

488  60827248 

44 

$00  96842361 

828 

914  60867496 

896 

9286887298 

558 

942  70887668 

48 

996  7680277 

408 

570  80817878 

438 

964  8883288 

3  75 

966.90848086 

33 

612688831W 

29 

827  00878286 

24 

641  00093369 

238 

699.11008986 

19 

•69  18023800 

1  38 

083  21030713 

1 

•97  28083010 

08 

711.31060623 

07 

729  36006030 

088 

739.41009139 

038 

793  48114237 

02 

767  91136343 

01 

761.98144447 

018 

769  81199993 

0 

606  68174897 

008 

823.71186761 

006 

637  78204868 

006 
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(2|  Activity  <Hem> 

I  Btock  Animation  |  Comments  | 


Process  |  Cost  [  ^uttfown  |  Preempt  |  Re&utts  |  Contents  |  ttem  Antmatwn  | 


Processes  one  or  more  items  simultaneousiy; 
outputs  each  item  as  soon  as  it  is  finished 


OK 


~[>efir>e  capacity 
Maximum  items  in  activity  |i~ 


"Specify  processing  time  (delay) - 

Delay  is*  Ispecified  by  a  diatnbutior>  J 
Distribution;  ll^rmai  ~ 


Delay  (0):  p3  696996^  tme  units 


Mean: 
Std  Dev: 


H 


Plot  Sample 


Q  Use  blocSi  seed  ^ 


"Oenne  other  processing  behavior  ' 
□Simulate  muttitasinng  activity 
Use  shift  I 


□Preempt  when  block  goes  off  shift 


Block  type  Residence 


PI  ActMty  <ftam> 


[2]  Activity  <nem> 
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Items  uistrKMJiion 


Woffcstieet  PtatoQs 


Intenmval  Timi 

iQik  Oim* 

0 

3 

2r92S1900«7 

1  3 

5.US22S013d 

106 

8.377S»»02O2 

00 

11.170*52027 

196 

13.9630S5034 

2 

is.7M«reo* 

10 

1«.54«2»1047 

215 

22.34080*004 

36 

23.133017001 

316 

27.»2ei3CKX7 

335 

30.716743074 

35 

33.011356061 

37 

36.303»6M>67 

4 

39.096062094 

37 

41.0661 99101 

36 

44.661008106 

5 

47.474421114 

516 

50.267034121 

41 

53.000647120 

305 

99  902260130 

306 

50.644673141 

406 

61.437466146 

435 

64  230099190 

36 

67.022712161 

2  75 

69.615329166 

35 

72.607908170 

336 

79.400001162 

105 

70.103164186 

24 

60.960777190 

32 

63.776390202 

1  7 

66.971003206 

11 

69.363616219 

0  75 

92.196229222 

1  15 

94.940642229 

0  75 

97  741499230 

006 

100.03406024 

036 

103  32660123 

04 

10611929426 

036 

108.91190726 

025 

111.70*02027 

03 

114.49713320 

01 

117.26974620 

01 

120.06239920 

0 

1220749723 

006 

129.6679803 

006 

120.46019031 

0 

131.26261132 

006 

134  04043402 

0 

136.03603733 

006 

|3]  Select  Item  Out  <ltem> 

Options  I  Item  Anwnation  |  Block  Animation  |  Comments  | 


Sends  each  Mem  to  a  selected  output 

I  Caftoel  I 


Speuily  selection  conditions 

Select  output  based  on  | random  3 

QUee  block  seed:  [4  1 

elect  options 

f  output  IS  blocked'  jitem  wa  was  rar  i  i  lutput  J 

^Predict  the  path  of  the  item  before  fl  entttfs  this  block 
^Show  throughput  on  icon 

To  Bioc«  PiebobMy  Thfouanput 

1 

<e.tO-  Nl»c  -''err*  QS  T40a 

2 

S4t»cn»m  lnI86]  0  2  1861 

Equal  ProbabMiaa  1 

□  snow  probabilities  on  icon 

Block  typo  Decision 

|3]  Select  Item  Out  <ttem> 


[  ToBtock 

PioboMOy 

ThreuBtipU 

1 

]s>a)o*  l*<wrt  PjhP* 

08 

7405 

3 

{setectlte'it  ln(86| 

02 

1881 

|3| 

Select  Item  Out 

<ltem> 
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[3]  Select  Item  Out  <ltem> 

|4]  Select  Hem  Out  <Rem> 

Options  [  Item  Animation  |  BiocR  Anmaton  |  Comments  | 


Sends  each  Item  to  4  selected  output  ^  ^ 

I  Cancel  | 

‘Specify  selection  conditions - 

Select  output  based  on  [fandom  J 

QUse  block  seed.  |5  ~| 


Select  options - 

If  output  is  blocked:  [  •lelii  wiw  Wfiii  Hit  ulutneU  uuiii 


QPredict  the  path  of  the  item  before  it  enters  this  block 
QShow  throughput  on  icon 


to  Btoc»  Probobity  Thiougtiput 

1 

0  8 

2 

Sc«ec1  Item  inpO]  0  2  ^ 

ED 

J 

Equal  Probabilities  j 


QShow  probabilities  on  icon 


Bfock  type  Decision 

[4]  Select  Item  Out  <ttem> 


ToQieek 

MaMiy 

Tiirauaheut 

1 

^ar.  Ir.oojfjl:! 

oa 

2 

S^ect  Itmr  ln(iai) 

02 

1408 

[4]  Select  Item  Out 

<ltem> 

(4|  Select  Item  Out  <ttem> 

|5]  Select  Item  Out  <Nem> 

Options  I  Item  Anwnation  |  Block  Animation  |  Comments  | 


Sends  each  Item  to  a  selected  output 

I  Cancel  I 

'Specify  selection  conditions 
Select  output  based  on  [random  J 

Q]  Use  block  seed.  |6  ] 


Select  options 

If  output  is  blocked :  jitem  ww  rra*  ~ 

QPredict  the  path  of  the  item  before  it  enters  this  block 


□Show  probabilities  on  icon 


Btock  type  Deasion 
[6]  Select  Item  Out  <ttem> 

tToBlodi  Pwittatr  Throughput 

>a*CT  p-.viie  OSS  -of.4 

select  Kid]  00$  38$ 

[S]  Select  Item  Out  <ltem> 
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(5]  Setect  Kem  Out  <ltem> 


Worksheet  Dialogs 


[6]  Activity  <ltem> 

I  Block  Animatwn  |  Comments 


Process 


]  Cost  I  ^utdown  I  Preempt  |  Results  [  Contents  |  Item  Animation  | 


Processes  one  or  more  iems  simirftaneously: 
outputs  each  item  as  soon  as  it  is  finished 

“Define  capacity 


OK 


Cancel 


Maximum  items  in  activity;  h 


3 


Specify  processing  time  (delay) 

Delay  iS'  {specified  by  a  distnbution  J 
Distribution:  llo^nonnai 

Mean;  [24  ~ 


Delay (D):  t:3  1140t0sT|time  unite 


Std  Dev: 


Location: 


Ell 


Plot  Sample 


Q  Use  btock  seed  [T" 


”  Define  other  processing  behavior  ‘ 

□Simulate  multitasking  activity 

Use  shift.  I 


"13  QPieempt  when  block  goes  oft  shift 


Block  type  Residence 


(63  Activity  <ltem> 


($3  Activity  <ltem> 


(6)  Hems’  Distribution 


Mo  suopofi  2  v9  -  23  Dec  1 4  mox 
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Worksheet  DUIoqs 


InMTMTTvai  Ttm* 


6.oeeei42oe7 

085 

662S61S49S7 

13 

e.iro62«6e28 

295 

s.riis29se8e 

35 

11.2S2S)9117 

495 

12.7936*0344 

95 

14.334649971 

9  75 

19.979660796 

SS 

17.416696029 

99 

16.967661292 

905 

M.49tte*4r* 

«.15 

22.033671706 

95 

23  960676933 

525 

29.12168216 

44 

26.683967366 

43 

28.203682619 

23 

29.744637942 

31 

31.296703098 

4 

32.626709299 

24 

34.367713923 

245 

38.90671679 

2  15 

37.449723977 

1  3 

39.960729204 

1  56 

40  931734431 

1  4 

42.072739696 

07 

43  613744989 

145 

49194790112 

106 

46.696799338 

0  25 

49  236760996 

096 

49  777769793 

03 

91.31677102 

0  45 

92.996776249 

03 

94.400761479 

04 

99.941766702 

03 

97.462731929 

03 

99  023787186 

015 

60.864802393 

025 

62.10960791 

01 

63.646612937 

02 

69.197919064 

005 

66.729923231 

0.2 

66.263626816 

01 

69.910633749 

Of 

71.391639972 

005 

72.8826*4196 

015 

74,4336*9426 

01 

79.974694693 

0 

77  91869966 

0 

79.096869106 

005 

60.997670339 

006 

Activity 

<ltem> 

Process  [  Cost  |  Shutdown  |  Pi^mpt  ]  Reaurts  |  Contents  |  Hem  Animatior)  | 


Processes  orM  or  more  Hems  senutteneously; 
outputs  each  item  as  soon  as  H  is  firtished 


OKI 


Cancet 


’Defir>e  capaoty 
Maximum  items  in  acbvity; 


3 


'  Speedy  processing  time  (delay) 

Delay  is;  (specxfied  by  a  distnbubon  J 
Distribution:  [Log norma) 


Delay  (0):  (l  35.1 6973641  time  units 


Mean 

Std  Dev: 


166 


Plot  Sample 


Location-  ^ 


(~|  Lise  block  seed  ^ 


’  Defirie  other  processing  behavior 
^Simulate  multitasking  activity 
Use  shift  I 


^  □Preempt  when  block  goes  oti  shift 


Block  typo  Residence 
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{7]  Activity  <Kefn> 


(7]  Activity  <Kem> 


[7]  Kerns’ Distribution 


Intervrrval  Tim* 

i[^  Ncmt 

U-i  • 

S7  5S40M847 

026 

79.729028139 

1  06 

89  8e7»114l8 

IS 

92.049634704 

2 

100  21197798 

296 

108.37346128 

38 

118  93831888 

97 

124.88722786 

6 

132.89811113 

71 

141  02089442 

786 

1481828777 

736 

197.34478088 

71 

189  80864428 

726 

173.88802798 

556 

181.63041086 

46 

189  99229413 

6 

196.1041 7742 

346 

208.31808071 

3  46 

214.47794388 

3  46 

232.63882728 

27 

230.80171008 

2.1 

238  96369380 

1  76 

247.12647713 

1  1 

299  28738042 

1  IS 

263  44934371 

09 

271  61112888 

086 

279  77301028 

075 

287  93489366 

075 

296  08677886 

075 

304  20686013 

026 

31242064342 

025 

320  96242671 

015 

328  74430988 

026 

336  90619328 

02 

348  08807888 

025 

393  22999986 

006 

381  38184314 

005 

389  96372642 

006 

Sn  71M0971 

0 

389  87748396 

005 

394  00837626 

0 

402  20129966 

006 

410  38314286 

0 

419.92602614 

005 

426  68680942 

0 

434  64679271 

0 

443  01067999 

0 

451  17269829 

0 

499  33444296 

005 
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[8]  Activity  <Hem> 

I  Btocfc  Animation  |  Comments  | 


Process  I  Cost  [  ^uttfown  |  Prxmpt  [  Results  |  Contents  |  ttem  AntmaUon  ] 


Processes  one  or  more  items  simultaneously; 
outputs  each  item  as  soon  as  it  is  finished 


OK 


’[>efir>e  capacity 
Maximum  items  in  activity  |i~ 


Specify  processing  time  (delay) - 

Delay  is*  Ispecified  by  a  diatnbutior>  J 
Distribution;  jfkirmar  ~ 


Delay  (D):  |l  6  0323670^1  time  units 


Mean: 
Std  Dev: 


12 


Plot  Sample 


!•]  ActMty  <ftam> 


[8]  Activity  <ltem> 

{9]  Select  Item  Out  <llem> 


Options  j  Hem  Anmation  |  Block  Animation  |  Comments 

Sends  each  item  to  a  selected  output 


OK 


r  Specify  selection  conditions  ' 


Select  output  based  on:  [random 
Q Use  Mock  seed  |i0 


:3 


r  Select  options 


Ifouiput  IS  blocked  [item  wrii  waa  to  biocked  output 
Q  Predict  the  path  of  the  item  before  rt  enters  this  block 
QShow  throughput  on  icon 


Ptobablty 


02 

OS 


ThroughpU 


EL 


Equal  Probabilities"") 
QShow  probabilities  on  icon 


Biock  type  Decision 


[9]  Select  Item  Out  <ltem> 
Tefileck 


2  js^or  R^AttoruJt 

[9]  Select  Item  Out  <ltem> 


vSf 

SOM 
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[9]  Select  Item  Out  <ltem> 


Wofltsheet  Dialogs 


[10]  Select  Item  In  <Kem> 

Optione  [  Bloctc  Ammetton  |  Comments  | 


Selects  an  input  and  outputs  Its  item  |  ^ 

{  Cancel  | 

“Specjfy  selection  rule - 

Select  input  based  on;  Imerge  ~~2 


’Select  options  and  report  throughput 


QShow  throughput  on  icon 


Pfor^ock  Tk/cugnput 

0 

Sid  Mai  '^-4 

1 

PartOndoardlSj  I'j;: 

3 

Parl^  Mcc 

W) 

_ 

Bfock  type  Dedsron 


[101 

Select  Hem  In 

<ltem> 

[10] 

Select  Hem  In 

<ltem> 

Frardibck 

ThreMihpdl 

0 

^lor  Par 

sew 

1 

Part  OnDoard|S] 

2es 

2 

Salcr  N«ed  Pai<4 

t40S 

[37]  Select  Item  Out  <ltem> 


Options  I  Item  Anenation  |  Blocfc  Animation  |  Comments 

Sends  each  Hern  to  a  selected  output 
’Specify  selection  conditions  ’ 


OK 


I  Cancel 


Select  output  based  on  Irarwlofn 
□  Use  block  seed  |38 


‘Select  options - 

Ifoutputie blocked:  •  'i  ..  •  , 

□  Predict  the  path  of  bie  item  before  it  enters  this  block 


□Show  probabilites  on  icon 


Block  type  Decision 


(37) 

Select  Hem  Out 

1  ToBtock 

<ltem> 

Throuaheut 

1 

ls«*<t  ltd'll  lr(A0] 

- **T}” 

ox 

2 

|s«actlt»rr  tn(aa) 

OS 

2083 

137) 

Select  Hem  Out 

<llwn> 

P7) 

Select  Hem  Out 

<ltem> 
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[40]  Select  Item  In  <ltefn> 

Options  I  Block  Animation  |  Comments  | 


1  OK  I 

Selects  an  input  and  outputs  its  item 

1  Cartcel  ] 

'Specify  selection  rule 

Seltcl  Input  based  on:  | merge 

Z33 

’  Select  options  and  report  throughput 


QShow  throughput  on  icon 


FrCfTfiMck  Tl-raiigriout 

0 

1 

2 

Piobimtllj  •JJi*.'' 

l 

Block  type  Decision 


[40] 

Select  Item  In 

<ltem> 

[40] 

Select  Item  In 

<ltem> 

riomMock 

D 

ntiiM  PTObiwr(7S4 

1 

1 

ProDienitlj 

0293 

2 

Sutler  R*-An*mp( 

7067 

[48]  Activity  <ltem> 


[48]  Activity  <llem> 


[48]  Activity  <ttem> 
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[50]  Select  Item  Out  <ltem> 

Options  I  ttem  Anmalion  |  Block  Animation  |  Comments 


Sends  each  item  to  a  selected  output 


OK 


I  Cancel 


'Specify  selection  conditions  ' 


Select  output  based  on  irandom 
□  Use  block  seed 


"Select  options - 

If outputis blocked  (re.n  wi*«  ^ 

□  Predict  the  path  of  the  item  before  k  enters  this  block 
□Show  throughput  on  icon 


>oBioM  ProboMtv  Throuonou 

1 

-  J..  Q  JJ  4  /•  ' 

2 

Select  Item  ln(661  01 

50 

...J 

□Show  probabilities  on  icon 
Biock  type  Decision 


ISO) 

Select  Item  Out 

<llem> 

1  Tr  Block 

PkobateMy 

ISO) 

1 

[Select  Item  l(i(S6I 

Select  Item  Out 

<ltem> 

1601 

Select  Item  Out 

<Hem> 

1611 

Select  Item  Out 

<ltem> 

ThfOiighpul 

4ad? 

557 


Options  [  ttem  Animalion  |  Block  Animation  |  Comments 


Sends  each  Rem  to  a  selected  output 


OK 


I  CarKei 


‘Specify  selection  conditions  ' 


Select  output  based  on  |random 
□Use  block  seed  |52 


Select  options  ‘ 


If  output  IS  blocked'  juem  win  wa*  Kw  Oiocweq  outp-' 

□  Predict  the  path  of  the  item  before  t  enters  this  block 

□  Show  throughput  on  icon 


o»  Seeking 
S<<gct  Item  ln[50] 


Probiblty  Ttnouplipm 


oa 

02 


951 


to 

^quaffroEaSiSesT*^^ 

□  Show  probabilities  on  Icon 

Block  type  Oeerson 
161)  Select  Item  Out  <ltem> 


f  TeBtock_ ftohebi>|f  Taiquahpt* 


1 

ICfSei  Of  Scavarg 

06 

C'vie 

2 

[select  Item  ln(50) 

02 

051 

1611 

Select  Item  Out 

<ltem> 

161] 

Select  Item  Out 

<ltem> 
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{52]  Activity  <ttefn> 


nimation  Comments 


Process  |  Cost  |  Shutdown  [  Preempt  [  Results  ]  Contents  ]  Item  Animation 

Processes  one  or  more  Kerns  simuitaneously: 
outputs  each  item  as  soon  as  K  is  finished 


Define  capacity  - 

Maximum  items  in  activity:  |1 

Specify  processing  time  (delay)  - 

Delayis:  {specified  by  a  distribution  , 
Distribution;  rCogn'ofmal 


Std  Dev:  1 2 


Define  other  processing  behavior  ' 
^Simulate  multitasking  activity 


Block  typo  Rosidonco 


[62]  Activrty  <Kem> 


Delay  (D);  t31  251032611  time  units 


QUse  block  seed; 


□  Preempt  when  block  goes  off  shift 


[62]  Activity  <nem> 


[S3]  Activity  <Kem> 
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[53]  Activity  <ltem> 


[53]  Activity  <ltem> 


[53]  Rems'  Distribution 


|S3]  Items' Distribution 


Intefwnval  Time 

iFK  Nems 

^  ~n 

M41«29r02 

44 

40.9S60S4rd 

00 

M.rmr24S 

112S 

60.9641602t 

090 

71.14e44r»4t 

1006 

ei.S327396ri 

8  75 

91.917023401 

88 

101.70131113 

70 

111.98099898 

535 

122.09M999e 

4  76 

191254iT49» 

185 

142.49999200 

3.5 

102.92274979 

360 

192.90703791 

235 

172.90132924 

1 

ie3.t7M1207 

1  6 

1932099007 

106 

203.94419942 

095 

213.72947910 

04 

223.91279999 

0  75 

234.09709192 

045 

244  20133930 

016 

294.44092709 

036 

244.04991492 

036 

274  93420299 

02 

399  01949039 

016 

290  20277801 

006 

309  30704974 

006 

31507139347 

01 

320  7004412 

006 

339  93992993 

0 

34613421660 

006 

006 

36649379212 

0 

376  67707990 

0 

304  09136799 

0 

397  04665531 

006 

407  23994304 

0 

417.41423077 

006 

427  9995180 

0 

437  79390433 

0 

447  9670938S 

0 

458  1  9138169 

0 

468  33098942 

006 

47891999716 

0 

488  70434499 

0 

496  88953261 

0 

609  07282034 

0 

919  2S710807 

006 
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(S4|  Activity  <lteni> 


[M]  Activity  <lt«m> 


[S4]  Activity  <)tem> 

[6S]  Select  Item  Out  <ltem> 

Options  I  Item  Anenation  |  Stock  Animation  |  Comments  | 

Sends  each  item  to  a  selected  output 

r  Speedy  selection  conditions - 

Select  output  based  on;  [random  J 

Q  Use  block  seed  ^  ~| 

r  Select  options - 

tfoutput  IS  blocked  (r,:in  puCp..-  J 

QPredict  the  path  of  the  Item  before  t  enters  this  block 
QShow  throughput  on  icon 


ToDiock  PiobaMtir  TiHOKHiput 

2 

w-\ 

os 

socct  toent  ln[»]  01  S37 

Equal  Probabifibes  1 

QShow  probabilities  on  Icon 


Block  type  Decision 


156] 

Select  Item  Out 

<ltem> 

1  To  Slock 

n-.6i-6.iay  Throughput 

1 

1 

OS  AS9: 

2 

(Saloct  ttwn  iri  'X.: 

01  S37 

166) 

Select  Item  Out 

<l(«n> 

I  OK  I 

I  CarKtl  I 
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Woffcshget  PtatoQs 

(95)  Select  Item  Out  <ltem> 

[59]  Select  Item  In  <ltem> 

Options  [  Blocfc  Ammation  |  Comments  | _ 


Selects  an  Input  end  outputs  Its  Item  ;  ' 

I  Cancel  | 

"Specify  selection  rule - 

Select  input  based  on:  [meroe 


"Select  options  and  report  throughput 


0Show  throughput  on  icon 


ffcr^oc*  Tfvougrioui 

0 

C  30ti  'Jv"- 

1 

P»itPmen(St]  96i 

2 

Jcreancf  Seed  S*  56’ 

l 

Bfock  type  Decision 


1*6) 

1561 

Select  Item  In 

Select  Item  In 

<ltem> 

<ltem> 

PfonfiMc 

ThrotWvut 

0 

CorCrarlDf 

3016 

1 

Pan  Pmeer^ll 

fi6l 

2 

ii^ereactor  fie«d  P 

56T 

176] 

Gat«  <KeiTO 

Qate  I  Block  Animetion  I  Comments  I 

- - - rsn 

Restricts  the  Row  of  Items  In  a  portion  of  the  model  i  ■.  > 

I  Cancel  ] 

■  Define  Gale  behavior - 

Type’  rco^itionai  ^ting  with  items  Demend  input  restricts  /tem  Itow 

QCrwck  demartd  at  each  event  Accumulated  demand:  |C'  ~| 

IRecheck  demand  connector  after  eacn 

3h,n  I  J 


B/ock  type:  Pessing 


[77]  Queue  <Rem> 
I  Comments 


I  Options  I  Results  |  Contents  |  item  Animation  |  Block  Animatioo  | 

items  wait  here  for  downstream  capacity 
"Select  queue  behavior: 


OK 


I  Cancel 


3  queue 


r  Select  sort  method  ' 


Sort  by  [First  In.  first  out  J 


Biock  type  Residence 
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[77]  Queue  <ltem> 

[71]  Create  <Reni> 

Create  |  Options  |  ttem  Animation  |  Block  Animation  |  Comments  | _ 

I  OK  1 

Creates  Hems  arxJ  values  ranrkmly  or  by  schedule  '  ' 

(  Cancel  I 

rSelectWock  behavior - 

ICreale  items  randomly  J  Time  units  generK* 


17S1  Create  <ltem> 
[7B]  Create  <item> 
[78]  Create  <ltem> 
[78]  Create  <item> 

I  I  2 
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Woffcstieet  PtatoQs 


itwamval  Timi 

iTlik  ■■m* 

409.3e0116S7 

0 1 

420  70$56944 

01 

43&0eM2» 

006 

491.38»«rS47 

015 

4««  74ae2e44 

04 

482  06838141 

065 

497.43883438 

04 

512.78S28734 

11 

528.13174031 

1  8 

543.47819328 

2  45 

558.82484825 

22 

674  17109922 

3 

989.61755218 

35 

804.86400915 

37 

620.21049812 

386 

639.65691108 

4  75 

650.90336406 

46 

666  24981702 

466 

681.98626868 

556 

696  84272296 

49 

712  2881 788<3 

506 

727.6396289 

536 

742.98208186 

46 

768  32853483 

37 

773  6749878 

43 

789.021440n 

4 

804.36789374 

36 

819  7143467 

36 

839.06079967 

24 

89040729264 

2  76 

669.79370961 

26 

861.10015698 

145 

896.44661194 

1  4 

911.79306491 

11 

927.13891748 

1  2 

942.48997049 

1  2 

997  83242342 

07 

873.17867630 

045 

989.92932939 

055 

1003.8717823 

0  45 

10192182353 

036 

1034  9649883 

025 

1049  9111412 

03 

1065  2575942 

035 

1080  6040472 

0 

1099  9905001 

01 

1111  2969931 

0 

1126  6434061 

0 

1141  989899 

01 

1157396312 

01 

|80|  Select  Nem  In  <ltem> 

I  Btoclc  Animation  |  Comments  | 


Selects  an  Input  and  outputs  Ns  Nem  . i 

1  Cancel  I 

'Specify  selection  rule  ■ 

Select  input  based  on;  fmerge  ~3 


'Selecf  options  and  report  throughput 


QShow  throughput  on  icon 


Frond  ocfc 

0 

1 

crOielor  F»e4|5 

557 

iin 

Biock  type  Decision 


ISO) 

Select  Item  In 

<ttem> 

[80] 

Select  Item  In 

<N8m> 

f  Pfondpck 

Thniuaheut 

0 

1 

4887 

1 

porOartor  Fii(«4(S 

637 
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|86]  Select  Item  In  <ltem> 

Options  I  Btocfc  Animation  |  Comments  | 


Selects  an  input  and  outputs  its  item  i. - J 

I  Cancel  | 

'Specify  seteclion  rule - 

Select  input  based  on;  imerpe  *3 


"Select  options  and  report  throughput 


QShow  throughput  on  icon 


Pfondock.  TVnogritiiji 

0 

1 

Satcf  Aflainpl  R*o  1M1 

El. 

J 

Bi^k  (ype  Oeosron 


(861 

Select  Item  In 

<ltem> 

186] 

Select  Item  in 

<ltefn> 

1  P«omBlock 

TivoMIhput 

0 

l^lor  N»  Anarrpe 

1000 

t 

^ior  Atisirvi  Pap 

taei 

[112]  Gate  <item> 


Gete  I  Block  Animation  |  Comments  | 

Restricts  the  now  of  items  in  a  portion  of  th«  model 


I  ox  I 

I  Cancel  ] 


'Oef)r>e  Gate  behavior - 

Type;  [conditional  gating  with  values^  Demand  input  nstncts  /fern  Ifow 
□Check  demand  at  each  event  Accumulated  demand:  |c 

■  •  ■  nanu  wtmcUm  ollci  cgvii  lictii  -  .| 

shm  I  J 


Stock  type  Passing 
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[189]  Equation  <Vaiue> 

Equation  |  Options  |  Comments  | 


Computes  an  equation  and  outputs  the  resuRs  |  -* 

I  Open  Devetoper  Reference  |  |  Canoe!  } 

"Define  input  and  output  vanables - 

Input  ^nabtes _  Output  Vanables  (results) 


I  VstMUtyp* 

Varvaoe  Nvrr* 

VarttM  Vaiu*  1 

1  I  Conr^ctorO 

,  irConO 

0299 

"  Enter  the  equation  in  the  form  'result  =  formula;* 


outConO  ~  inConO  *  1. 

1  Open  /  Cloee  Equation  Edtor  I 

□Enable  Debugger  |  Set  Breakpointa  1 

1  Test  Equation  1 

QUse  include  files 


|1«91 

Equation  <Value> 

VvwMeType  Vvabte  Name 

Vanabte  Value 

[189] 

Cerrierry  0  ^  rCarO 

Equation  <Value> 

eya-i 

VwiatM  Type  Varobie  NaiTie 

Venable  Value 

CcrreoyO  .  ccfCcrO 

6»4 

11891 

Equation  <Value> 

[22B] 

Select  Item  In  <ltem> 

Options  I  Block  Animation  |  Comments  | 


Selects  an  input  and  outputs  Hs  item  ^  * 

ICancel  | 

"Specif/ selection  rule  - 

Select  input  based  on;  [merge  3 


~  Select  options  and  report  throughput 


QShow  throughput  on  icon 


FfOfrfilOCk 

IfV-DliC^Dut 

0 

14:..' 

1 

-  rrrTacrrr  Fb{103 

4M6 

3 

0 

3 

0 

E3 _ 

B^ock  type  Decrsion 
[229]  Select  Hem  In  <nem> 
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Wofkslieet  Dialogs 


[22S]  Select  Item  In  <ltem> 


FiorflKxft 

Ttvcuevut 

0 

Sartor 

f407 

t 

l^ort^ctor  RkIIOS 

4666 

2 

0 

3 

0 

1231) 

Exit  <ltem> 

Report  I  Animation  |  Comments  | 


Passes  Mems  out  of  the  simulation  | _ _  - 

[  Cancel  I 

“Reports  results - 

I  NufTfetf  6i>»e  ignw 

i  1  6293  B 


I 

Stock  type  Residence 
[231]  Exit  <ltem> 


Total  e)«ted 
|6293  I 


1 

'  NufTbar  e«Md  ignora  Rasaft 

’  1 

6293  H 

[237]  WrTte(l)  <}lem> 

Write  Data  |  Options  |  Item  Animatwn  |  Block  Animation  |  Comments  | _ 

Writes  data  to  a  database  when  an  Hem  arrives  [  j 

I  Cancel  I 

r  Select  database  and  define  database  coordinates - 


Database  [Database  \  J  |  Open  selected  database  ]  [  Open  selected  table  ] 


Block  type  Pessing 
[237]  WrHe[l)  <ltem> 


1  WmKwna 

TaM» 

F)al(l 

RaoeW  OBT^R 

Wnta 

i/iVta  Sourca  Vslua  VkR<t<>*r 

1  I  Wl 

Otitpu 

^  TanaToRapaif, 

CerO  ,  ^.1  , 

RV 

*  *  4ei  2161?&C-t-7si 
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[238]  Equation (I)  <ltem> 

Equation  |  Options  |  Item  Animation  ]  Block  Animation  |  Comments  | 


Computes  an  equation  when  an  item  arrives  and  outputs  the  resutts 


OK 


Open  Developer  Refererce  ]  (  Cancel 


Define  input  and  output  vanablee 
Input  Vana  bias 


V»iabt»Valu» 


Bi«9iTiin»  -S244MS  3064718 


Output  Vianabies  (results) 


'  Enter  the  equation  in  the  form  'result  ■  formula;" 


Age  s  Current  Time-BirthTime. 


I  Open  /  Close  Equation  Ed<or  I  □  Enable  Debugger  |  Sel  Breakpoints  I  I  Test  Equation  I 


□  Use  include  files 
Block  typo 


Passing 

[238]  Equation(l)  <ltem> 


1  VanabteTfpe 

Vanaoe  Name 

Vanabte  Value 

*  1  Attrt»Jle 

^  fre  ^ 

^244a<0  3064718 

[238]  Equation(l)  <ltem> 

1  V«i«bleT)fipe 

Vanabla  Name 

Vviabte  Value  M  no  dem  use 

*  1  Anrt«j» 

48'  2161750S234 

[238]  Equation(l)  <ltem> 
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[241]  Wnte(l)  <ttem> 

Write  DaU  |  options  |  ttem  Antmatwn  |  Block  Animation  |  Comments  | 


Writes  data  to  a  database  when  an  Aem  arrives  i - —i 

(  Cancel  I 

'Select  database  and  define  database  coordinates - 


Database  | Database  t  J  |  Open  selected  database  |  [  Open  selected  table  | 


Block  type  Passing 
[241]  Write(l)  <ltem> 


1  V\^rt»Nanw 

Taoe 

FiM 

OfiTFR 

Wht» 

Vatte  Source  Vatut  VM-tten 

1  1 

Outpc* 

^  TrwToAepaar^ 

CcrO  , 

^  J  K 

PV 

«  l  «  436  «9e36S80A3A 

[242]  Equatlon(l]  <ltem> 

Equation  |  Options  |  Item  Animation  |  Block  Animation  |  Comments  | 


Computes  an  equation  when  an  Hem  arrives  and  outputs  the  results  |  * 

I  Open  Developer  Reference  \  \  Cancel  | 

•  Define  Input  and  output  variables - 


Output  Variables  (results) 


'Enter  the  equation  in  the  form  'result  ■  formula;" 


Age  s  CunrentTIme'BIrthTIme. 


I  Clp«n  /  CIOM  Equation  Edilor  I  □Enable  Debugger  |  Sel  Bteakpoinle  |  |  Teel  Equation  I 


QUse  include  files 
Block  type 


Passing 

[242]  Equation(l]  <ltem> 


[  VarableType 

VartaOto  Narrw  Vwtabte  Value 

••  I  AftrKr^ 

,  &nt»TT>w  ^  5250528  3000382 
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[242]  Equation(l)  <ltem> 


1  VanabieTyve 

Vanabie  Name  Vanabte  Value  S  no  Mm  uie 

’  1  Attrbuia 

^  Aoe  ^  436  48B3fiee0434 

[242]  Equetlon(l)  <ltem> 


[268]  Activity  <ltem> 

Btock  Animation  I  Comments 


Process  |  Cost  |  Shutdown  |  Preempt  |  Resists  |  Contents  |  item  Animation  | 


Processes  one  or  more  Hems  simultaneously: 
outputs  each  item  as  soon  as  it  is  finished 


OK 


Cancel 


Define  capacity 

Maximum  items  in  activity;  |i~ 


3 


■  Specify  processing  time  (delay)  - 

Delay  is  ispeerfted  by  a  distnbulion  J 
Distribution:  [Normal  ~ 

Mean  |500 


3 


Delay  (D):  ^397  9387021  |  time  unite 


Plot  Sample  | 


Q  Use  block  seed  ^9 


Define  other  processing  behavior  ' 
Q  Simulate  multitasking  activity 
Use  shift  I 


Q  Preempt  when  block  goes  off  shift 


Biock  type  Residence 


[268]  Activity  <ttem> 


[268]  Activity  <ltem> 

[284]  Create  <nem> 

Create  |  Options  |  Item  Animation  ]  Block  Animation  |  Comments  | 


Creates  Hems  ar>d  values  randomly  or  by  schedule  ^  ^ 

[  Cancel  ] 


'  Select  options  for  scheduled  item  creation 

[Create  items  by  schedule  J 

Time  units  generic* 

Start  connector:  Ifoliows  schedule 

J 

"Other  options - 

QShow  connector  names 


Block  type  Residence  ‘model  default 

[284]  Create  <ttem> 


No  support  2  v9  •  23  Dec  14  mox  <  southerndbaidaSDesktooiDSHELL-  1>-  Paoe  -25 


366 


LIST  OF  REFERENCES 


ACQNotes.  2014.  “CDD  In  The  Acquisition  /  JCIDS  Process.”  Accessed  January  17, 
2015.  http ://acqnotes. com/ acqnote/ acquisitions/capability-development- 
document-cdd 

Alexander,  Jeff.  2008,  Jeff  Alexander’s  Web  Blog,  May  4. 

http://blogs.technet.com/b/jeffa36/archive/2008/05/05/mof-4-0-available-for- 

download.aspx. 

AXELOS  Ltd.  2011.  Information  Technology  Infrastructure  Library.  Standard,  London: 
UK  Government 

Blanchard,  Benjamin,  and  Wolter  Labrycky.  2011.  Systems  Engineering  and  Analysis. 
5th.  Upper  Saddle  River,  NJ:  Prentice  Hall. 

Buede,  Dennis  M.  2009.  The  Engineering  Design  of  Systems  Models  and  Methods. 
Hoboken,  NJ:  John  WIley&  Sons. 

Candes,  E  J,  and  M  B  Wakin.  2008.  People  Hearing  Without  Listening:  An  Introduction 
to  Compressive  Sampling.  Scientific  Paper,  Pasadena:  California  Institute  of 
Technology,  Applied  and  Computational  Mathematics. 

Chief  of  Naval  Operations.  2007.  Navy  Distance  Support  Policy.  Memorandum, 
Washington,  DC:  Department  of  Navy. 

CISCO  Inc.  2014.  “Networking  Basics.  ”  Last  modified  December  10. 

http://www.cisco.com/cisco/web/solutions/small_business/resource_center/article 

s/connect_employees_and_offices/networking_basics/index.html 

Defense  Acquisition  University.  2011.  DOD  Life  cycle  Management  &  Product  Support 
Manager  Rapid  Deployment  Training.  Presentation,  Belvoir:  Department  of 
Defense. 

- .  2012.  Glossary  of  Defense  Acquisition  Acronyms  and  Terms  -  Measure  of 

Performance  (MOP).  Accessed  January  17,  2015. 
https://dap.dau.mil/glossary/pages/2236.aspx 

- .  2014.  ACQuipedia  DOTmLPF-P  Analysis.  Last  modified  March  14. 

https://dap. dau.mil/acquipedia/Pages/ ArticleDetails.aspx?aid=dl  Ib6afa-al6e- 
43cc-b3bb-ff8c9eb3e6f2 


367 


- .  2014.  ACQuipedia  Key  Performance  Parameters  (KPPs).  Last  modified 

September. 

https://dap. dau.mil/aequipedia/Pages/ ArtieleDetails.aspx?aid=7de557a6-2408- 
4092-8 171-23a82d2el6d6 

- .  2012.  Glossary  of  Defense  Acquisition  Acronyms  and  Terms  -  Measure  of 

Effectiveness  (MOE).  Aeeessed  January  17,  2015. 
https://dap.dau.mil/glossary/pages/2236.aspx. 

Department  of  Defense  Chief  Information  Offieer.  2009.  Clarifying  Guidance  Regarding 
Open  Source  Software  (OSS).  Memorandum,  Washington,  DC:  Department  of 
Defense, 

- .  2006.  “Foundation  Doeuments  Volume  1  of  Department  of  Defense  Chief 

Information  Offieer  Desk  Referenee.”  DOD  CIO.  Last  modified  August, 
http  ://dodeio  .defense.  gov/Portals/ 0/Doeuments/eiodesrefvolone.pdf 

Department  of  Defense.  2000.  Department  of  Defense  Laser  Master  Plan.  Plan, 
Washington,  DC:  Department  of  Defense. 

- .  2006.  Risk  Management  Guide  for  DOD  Acquisition.  Guidebook,  Washington, 

DC:  Department  of  Defense. 

- .  2012.  Manual  for  the  Operation  of  the  Joint  Capabilities  Integration  and 

Development  System.  Manual,  Washington,  DC:  United  States  Government. 

- .  2014.  DEFENSE  AND  PROGRAM-UNIQUE  SPECIFICATIONS  FORMAT 

AND  CONTENT  (MILSTD  96 IE).  Military  Standard,  Washington,  DC: 
Department  of  Defense. 

- .  2014.  Risk  Management  Framework  (RMF)  for  DOD  Information  Technology 

(IT).  Instruetion,  Washington,  DC:  Department  of  Defense. 

Department  of  Navy.  2014.  Department  of  Navy  Chief  Information  Officer,  The 

Transition  Begins:  DOD  Risk  Management  Framework.  Last  modified  June. 
http://www.doneio.navy.mil/CHIPS/ArtieleDetails.aspx?id=5015 

- .  2015.  Defense  Readiness  Reporting  System  -  Navy  Overview  Course. 

Presentation,  Washington,  DC:  Department  of  Defense 


368 


Eclipse  Foundation.  2014.  Open  Systems  Engineering  Environment  -  V Diagram. 
Accessed  January  7,  2015. 

http://www. eclipse. org/osee/imagesA^Diagram_sm.png 

Flatieon.  2014.  Creative  Commons.  Free  vector  icons.  Accessed  Oetober  2014. 
http://www.flaticon.com 

Guertin,  Nicholas  H,  and  Paul  Bruhns.  2011.  “Comparing  Acquisition  Strategies: 

Maintenance  Free  Operating  Period  vs.  Traditional  Fogistics  Support.”  Excerpts 
from  the  Proceedings  of  the  Eighth  Annual  Acquisition  Research  Symposium 
Thursday  Sessions  Volume  11.  Monterey:  Naval  Postgraduate  Sehool:  471-472. 

Halligan,  Robert.  2014.  Project  Performance  International.  Aceessed  Deeember  30, 
2014.http://www.ppi-mt.eom/systems-engmeermg/types-of-requirements.php 

Harney,  Robert  C.  2012.  Laser  Engineering  Using  Rate  Equation  Theory.  Monterey: 
Naval  Postgraduate  School 

Hegde,  Sandeep,  and  Vasudeo.  2012.  Challenges  Posed  by  Job  Satisfaction  and  Security 
for  Employees  of  Selected  Voice  Process  Call  Centers  in  Mumbai .  Study, 

Mumba:  Tilak  Maharashtra  Vidyapeeth 

IEEE.  2014.  “Standard  Framework  for  Prognosties  and  Health  Management  of  Electronic 
System  (PI 856).”  IEEE  Standards  Association.  Accessed  December  1 1 
http  ://standards  .ieee.org/ 

International  Couneil  On  Systems  Engineering.  2010.  INCOSE  3rd  Edition.  Handbook, 
San  Diego:  INCOSE. 

International  Organization  for  Standardization  (ISO)  and  the  International 

Eleotroteohnieal  Commission  (lEC).  2014.  Information  Technology  Service 
Management  -  Part  I:  Service  Management  System  Requirements  (ISO  20000- 
1:2011).  Standard,  Geneva:  ISO. 

ISACA  .  2013.  “COBIT  5  Cheat  Sheet.”  Mmzmar Ac.  Aceessed  Deeember  17,  2014. 
http://www.isaca.org. 

Jackson,  Peter.  1998.  Introduction  to  Expert  Systems.  Boston:  Addison  Wesley. 


369 


Levis,  A.  1993.  National  Missile  Defense  (NMD)  Command  and  Control  Methodology 
Development.  Contract  Data  Requirements  List  A005  report  for  U.S.  Army 
Contract  MDA  903-88-0019  Delivery  Order  0042,  Fairfax,  VA:  George  Mason 
University  Center  of  Excellence  in  Command,  Control  Communications,  and 
Intelligence. 

Madachy,  Raymond.  2014.  COCOMO  Suite  of  Constructive  Cost  Models.  Accessed 
December  10.  littps://diana.nps.edu/~madacliy/tools/COCOMOSuite.php 

Madachy,  Raymond.  2014.  Systems  Engineering  Cost  Estimation  Workbook.  Workbook, 
Monterey:  Naval  Postgraduate  School. 

Mathai,  Paul.  2011.  Big  Data,  Catalyzing  Performance  in  Manufacturing.  Research 
Whitepaper,  Bangalore:  Wipro  Council  for  Industry  Research, 

Meijer,  Gerard.  2008.  Smart  Sensor  Systems.  New  York:  John  Wiley  &  Sons. 

Nagios  Organization.  2014.  Nagios  Official  Site.  Accessed  December  10. 
http://www.nagios.org 

National  Institute  of  Standards  and  Technology.  1993.  “Draft  Federal  Information 
Processing  Standards  Publication  183.”  Integration  Definition  for  Function 
Modeling  (IDEFO).  Wright-Patterson  Air  Force  Base,  OH:  Secretary  of 
Commerce,  December  21. 

National  Instruments.  2008.  Five  Tips  to  Reduce  Measurement  Noise.  Accessed 
December  3,  2014.  http://www.ni.com 

Naval  Sea  Systems  Command.  2012.  NAVSEA  Warfare  Systems  Certification  9410.2A. 
Instruction,  Washington,  DC:  Department  of  Navy. 

Naval  Surface  Warfare  Center,  Port  Hueneme  Division.  2003.  Next  Generation  Distance 
Support.  Whitepaper,  Port  Hueneme:  NAVSEA. 

- .  2013.  Distance  Support  Handbook.  Port  Hueneme,  NAVSEA.  December  10. 

- .  Air  Dominance  Department.  2013.  Ship  System  Data  Collection  and  Analysis 

Framework.  Whitepaper,  Port  Hueneme:  NAVSEA 


370 


Nyquist ,  Harry,  and  Claude  Shannon.  2012.  “Nyquist-Shannon  Sampling  Theorem.” 
Princeton  University.  Aecessed  December  13,  2014. 

https://www.prmceton.edu/~achaney/tmve/wikil00k/docs/Nyquist%E2%80%93S 

hannon_sampling_theorem.html 

Office  of  Naval  Research.  2014.  “All  Systems  Go:  Navy’s  Laser  Weapon  Ready  for 
Summer  Deployment.”  Washington,  DC:  ONR. 

- .  2014.  Data  Focused  Naval  Tactical  Cloud.  Information  Package,  Washington, 

DC:  ONR. 

O’Rourke,  Ronald.  2014.  Navy  Shipboard  Lasers  for  Surface,  Air,  and  Missile  Defense: 
Background  and  Issues  for  Congress.  Congressional  Research  Service  Report 
(R41526),  Washington,  DC:  Department  of  Navy 

Paschotta,  Rudiger.  2014.  RP  Photonics  Consulting  -  Solid  State  Lasers.  Accessed 
Decmber  16,  2014.  http://www.rp-photonics.com/solid_state_lasers.html. 

Perram,  Glenn,  Cusumano  Salvatore,  Robert  Hengehold,  and  Steven  Fiorino.  2010. 

Introduction  to  Laser  Weapon  Systems.  Albuquerque,  NM:  The  Directed  Energy 
Professional. 

Perry,  William  J.  1994.  Specifications  &  Standards  -  A  New  Way  of  Doing  Business. 
Memorandum  for  Secretaries  of  the  Military  Departments,  Department  of 
Defense,  Washington,  DC:  Secretary  Of  Defense 

Porsche,  I,  B  Wilson,  E  Johnson,  S  Tierney,  and  E  Saltzman.  2014.  Data  Flood,  Helping 
the  Navy  Address  the  Rising  Tide  of  Sensor  Information.  Research  Whitepaper, 
Santa  Monica:  RAND  National  Research  Institute 

Project  Management  Institute.  2004.  A  Guide  to  the  Project  Management  Body  of 

Knowledge  (PMBOK  guide).  Newton  Square,  PA:  Project  Management  Institute. 

Qiu,  Hal,  and  Lee,  Jay.  2015.  Near-zero  downtime:  Overview  and  trends.  Accessed 
March  09,  2015.  http://www.reliableplant.com/Read/697I/downtime-trends. 

Service  Oriented  Architecture  Organization.  2013.  Service  Oriented  Architecture 
Manifesto.  Manifesto,  Creative  Commons. 

Smith,  William  J,  Kristopher  D  Leonard,  and  Chad  E  Jones.  2012.  Implementation  of 
Distance  Support  to  Reduce  Total  Ownership  Cost.  Abstract,  Belvoir:  Defense 
Technical  Information  Center. 


371 


Snider,  Barry.  2011.  The  Fourth  Plant  Maintenance  Revolution.  Accessed  March  09, 
2015.  https://inspectioneering.eom/j ournal/20 1 1  -09-0 1/22/the-fourth- 
maintenance-revolut 

Solarwinds  Inc.  2014.  Solarwinds  Official  Site.  Accessed  December  10. 
http://www.solarwinds.com/ 

Spiceworks  Inc.  2014.  Spiceworks  Official  Site.  Accessed  December  10. 
http://www.spiceworks.com/ 

Splunk  Inc.  Splunk  Products.  2014.  Accessed  December  10. 
http://www.splunk.com/product 

United  States  Congressional  Research  Service.  2014.  United  States  Navy  Shipboard 
Lasers  for  Surface,  Air,  and  Missile  Defense:  Background  and  Issues  for 
Congress.  (R41526).  Congressional  Report,  Washington,  DC:  United  States 
Government 

United  States  Department  of  Defense.  2004.  Maintenance  of  Military  Materials. 
Directive  ,  Wasington  DC:  Department  of  Defense 

- .  2013.  Open  Systems  Architecture  Contract  Guidebook  for  Program  Managers 

Version  1.1.  Guidebook,  Washington,  DC:  United  States  Department  of  Defense 

- .  2015.  Office  of  the  Deputy  Assistant  Secretary  of  Defense  Initiative  -  Open 

System  Architecture.  Last  modified  January,  28.  Accessed  February  18. 
http://www.acq.osd.mil/se/initiatives/init_osa.html 

United  States  Government  Accountability  Office.  2013.  Department  of  Defense 

Initiatives  on  High  Energy  Lasers  Have  Been  Responsive  to  Congressional 
Direction  (GAO-05-545R).  Report,  Washington,  DC:  United  States  Government 
Accountability  Office 

University  of  Southern  California.  2014.  Center  for  Systems  &  Software  Engineering 

Unified  Code  Count  Tool.  Accessed  December  3.  http://sunset.usc.edu/ucc_wp/ 

Unknown.  2010.  “Waiting  Line  Models.”  In  Supplement  C,  by  Unknown,  XX. 
Sacramento:  California  State  University  -  Sacramento 


372 


Webb,  Natalie  J,  and  Phillip  J  Candreva.  2006.  “Diagnosing  Performanee  Management 
and  Performanee  Budgeting  Systems:  A  Case  Study  of  the  USN.”  In  Public 
Fianance  &  Management:  PFM  Vol.  6  No. 2,  by  Guido  von  Wolswijk,  524-555. 
Monterey:  Naval  Postgraduate  Sehool 

Zabbix  Inc.  2014.  Zabbix  Official  Site.  Accessed  December  10,  2014. 
http://www.zabbix.com 


373 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


374 


INITIAL  DISTRIBUTION  LIST 


1 .  Defense  Teehnieal  Information  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  Sehool 
Monterey,  California 


375 


